From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From msemtd at googlemail.com Thu Aug 12 04:59:43 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 11:59:43 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Message-ID: On 12 August 2010 10:33, M.Dec-GM wrote: > When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. > Because of this observation I have thought what may be faster as a normal message events queue. > Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! > Basing on this idea I have decide to NOT use serial events. > Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. > Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. > This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Hi Mariusz, That's a very effective and creative approach. You could consider a technique from the Java concurrency API, such as a LinkedBlockingDeque to share messages with the main application. That is my usual approach -- I will be posting a working example on the wiki when I have time. If you put your code on the wiki also then the users will have more examples to work from. Regards, Michael. From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From msemtd at googlemail.com Thu Aug 12 04:59:43 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 11:59:43 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Message-ID: On 12 August 2010 10:33, M.Dec-GM wrote: > When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. > Because of this observation I have thought what may be faster as a normal message events queue. > Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! > Basing on this idea I have decide to NOT use serial events. > Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. > Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. > This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Hi Mariusz, That's a very effective and creative approach. You could consider a technique from the Java concurrency API, such as a LinkedBlockingDeque to share messages with the main application. That is my usual approach -- I will be posting a working example on the wiki when I have time. If you put your code on the wiki also then the users will have more examples to work from. Regards, Michael. From psuhas at gmail.com Thu Aug 12 14:57:52 2010 From: psuhas at gmail.com (Suhas Pharkute) Date: Thu, 12 Aug 2010 14:57:52 -0600 Subject: [Rxtx] Error in Java Message-ID: Hi, I am getting an error when I load an applet in xulrunner app (mozilla) java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: no suitable image found. Did find: /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper When I did my research it shows me that I need to use -d32 option while launching JVM. I am not sure how to do that? Can some one please help. Thank you, Suhas Pharkute (805) 229-1450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 00:37:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:37:39 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >>> I would also suggest that by using JNA we could get rid of the C code >>> altogether, making (no pun intended) building the code a trivial effort. > >> Anything that would make it easier to deploy and have less reliance on native >> code would be greatly appreciated from a end-user?perspective.? > > With JNA all the interface code is pure Java and JNA itself is a single .jar > file, so deployment is very simple. No platform specific native libraries, > DLLs etc etc. All you need is the jna.jar file in your classpath and > that is it. Or package the jna.jar with your Java application code and > you have a single cross platform executable solution. > > For an example on how easy it is to call standard C library printf from Java > in Mac OS X / Linux / Windows see: > > http://en.wikipedia.org/wiki/Java_Native_Access > > For details see the project home at: > > https://jna.dev.java.net/ > > From tjarvi at qbang.org Mon Aug 16 00:47:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:47:39 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > >> The attached patch is cumulative - it includes the previous patches. >> >> A number of changes to make RXTXCommDriver and CommPortIdentifier >> thread-safe: >> >> 1. Converted CommPortIdentifier linked list to a HashMap and moved it to >> RXTXCommDriver, put RXTXCommDriver in control of the Map and have >> CommPortIdentifier delegate method calls to RXTXCommDriver. >> >> There was a flaw in the design. One thread could be traversing the linked >> list while another thread is modifying it - causing unpredictable results >> or NPEs. >> >> 2. Synchronized access to the listener Vector in CommPortIdentifier. >> >> 3. Fixed the open method in CommPortIdentifier. Even though the method >> included synchronized blocks, it was not thread-safe - another thread could >> change the object's state in the gaps between the synchronized blocks. >> >> This will be my last patch for now. If these changes make it into the >> project, then I will submit more. >> > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the changes this week. > I'll let you know if I find anything. > I'm just following up to let you know this isnt sitting on a dusty shelf. The patches look fine. I have a meeting Tuesday about testing them. There is a possibility to streamline the process on my end so I'm taking the time to do it. Basically, I use rxtx at work as well and have access to a build and test system that covers the main platforms and has tests used since ~2000 for rxtx. I suspect I'll be able to push this through a set of nontrivial tests Wednesday. Maybe we can get some code coverage numbers as a bonus. I'm also looking at making the tests available outside of that harness. Its something I'm in favor of but takes more than a Tuesday meeting :) -- Trent Jarvi tjarvi at qbang.org From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From msemtd at googlemail.com Thu Aug 12 04:59:43 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 11:59:43 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Message-ID: On 12 August 2010 10:33, M.Dec-GM wrote: > When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. > Because of this observation I have thought what may be faster as a normal message events queue. > Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! > Basing on this idea I have decide to NOT use serial events. > Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. > Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. > This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Hi Mariusz, That's a very effective and creative approach. You could consider a technique from the Java concurrency API, such as a LinkedBlockingDeque to share messages with the main application. That is my usual approach -- I will be posting a working example on the wiki when I have time. If you put your code on the wiki also then the users will have more examples to work from. Regards, Michael. From psuhas at gmail.com Thu Aug 12 14:57:52 2010 From: psuhas at gmail.com (Suhas Pharkute) Date: Thu, 12 Aug 2010 14:57:52 -0600 Subject: [Rxtx] Error in Java Message-ID: Hi, I am getting an error when I load an applet in xulrunner app (mozilla) java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: no suitable image found. Did find: /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper When I did my research it shows me that I need to use -d32 option while launching JVM. I am not sure how to do that? Can some one please help. Thank you, Suhas Pharkute (805) 229-1450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 00:37:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:37:39 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >>> I would also suggest that by using JNA we could get rid of the C code >>> altogether, making (no pun intended) building the code a trivial effort. > >> Anything that would make it easier to deploy and have less reliance on native >> code would be greatly appreciated from a end-user?perspective.? > > With JNA all the interface code is pure Java and JNA itself is a single .jar > file, so deployment is very simple. No platform specific native libraries, > DLLs etc etc. All you need is the jna.jar file in your classpath and > that is it. Or package the jna.jar with your Java application code and > you have a single cross platform executable solution. > > For an example on how easy it is to call standard C library printf from Java > in Mac OS X / Linux / Windows see: > > http://en.wikipedia.org/wiki/Java_Native_Access > > For details see the project home at: > > https://jna.dev.java.net/ > > >From the perspective of rxtx this is another possible direction. We don't need to decide if it is _the_ direction. Don't try to load the wagon with developers, show its the way to go. If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. The solution and problems presented by JNA are an interesting area I've been pondering. This falls more along the lines of catering to some platform specific APIs but using as little of them as possible. Catering to platform specific APIs is a net loss in my opinion but maybe it works. It moves the platform independance responsibility to rxtx in the end. I don't see that we have the resources to do this more than once. The original idea for rxtx was to target POSIX not to become POSIX. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Aug 16 00:47:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:47:39 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > >> The attached patch is cumulative - it includes the previous patches. >> >> A number of changes to make RXTXCommDriver and CommPortIdentifier >> thread-safe: >> >> 1. Converted CommPortIdentifier linked list to a HashMap and moved it to >> RXTXCommDriver, put RXTXCommDriver in control of the Map and have >> CommPortIdentifier delegate method calls to RXTXCommDriver. >> >> There was a flaw in the design. One thread could be traversing the linked >> list while another thread is modifying it - causing unpredictable results >> or NPEs. >> >> 2. Synchronized access to the listener Vector in CommPortIdentifier. >> >> 3. Fixed the open method in CommPortIdentifier. Even though the method >> included synchronized blocks, it was not thread-safe - another thread could >> change the object's state in the gaps between the synchronized blocks. >> >> This will be my last patch for now. If these changes make it into the >> project, then I will submit more. >> > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the changes this week. > I'll let you know if I find anything. > I'm just following up to let you know this isnt sitting on a dusty shelf. The patches look fine. I have a meeting Tuesday about testing them. There is a possibility to streamline the process on my end so I'm taking the time to do it. Basically, I use rxtx at work as well and have access to a build and test system that covers the main platforms and has tests used since ~2000 for rxtx. I suspect I'll be able to push this through a set of nontrivial tests Wednesday. Maybe we can get some code coverage numbers as a bonus. I'm also looking at making the tests available outside of that harness. Its something I'm in favor of but takes more than a Tuesday meeting :) -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 16 08:32:25 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 07:32:25 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <54491.35492.qm@web63107.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > > > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > >> The attached patch is cumulative - it includes the > previous patches. > >> > >> A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > >> > >> 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > >> > >> There was a flaw in the design. One thread could > be traversing the linked list while another thread is > modifying it - causing unpredictable results or NPEs. > >> > >> 2. Synchronized access to the listener Vector in > CommPortIdentifier. > >> > >> 3. Fixed the open method in CommPortIdentifier. > Even though the method included synchronized blocks, it was > not thread-safe - another thread could change the object's > state in the gaps between the synchronized blocks. > >> > >> This will be my last patch for now. If these > changes make it into the project, then I will submit more. > >> > > > > Thanks Adrian, > > > > I'll be reviewing these and running a test suite on > the changes this week. I'll let you know if I find > anything. > > > > I'm just following up to let you know this isnt sitting on > a dusty shelf. > > The patches look fine.? I have a meeting Tuesday about > testing them. There is a possibility to streamline the > process on my end so I'm taking the time to do it.? > Basically, I use rxtx at work as well and have access to a > build and test system that covers the main platforms and has > tests used since ~2000 for rxtx. > > I suspect I'll be able to push this through a set of > nontrivial tests Wednesday.? Maybe we can get some code > coverage numbers as a bonus. > > I'm also looking at making the tests available outside of > that harness. Its something I'm in favor of but takes more > than a Tuesday meeting :) You must have missed my previous reply. Don't worry about that patch - I have abandoned work on 2.x in favor of a rewrite. I will have a formal V3 proposal ready in about a week. The first patch should get committed though - the one that fixes the properties file issues. In fact, that should be backported to previous versions. -Adrian From adrian.crum at yahoo.com Mon Aug 16 09:08:55 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 08:08:55 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <370266.35744.qm@web63104.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user?perspective.? > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction.? We don't > need to decide if it is _the_ direction.? Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory.? If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering.? This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works.? It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian From mariusz.dec at gmail.com Mon Aug 16 11:26:43 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Mon, 16 Aug 2010 19:26:43 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <0C4CFD3F08FE4FCCBD2F297DB56928EB@mdam2> Hi all, A bit Off Topic.... And we are going "back to the future" :))). Java was developed to be platform independent. Very nice idea but.... who knows Operating Systems rules, know what about I am thinking. Finally - everybody is looking how to do Java platform dependend because of ... performance. Surprise or not??? Ok - this example from Wiki gives multiplatform code on the higher level than conditionals in C code and THIS IS a very big step ahead comparing to early 90'ths... I am not Java enemy, but Java's overhead (in fact OS over OS) should be very carefully analysed before use Java on the small/relative slow platforms. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Monday, August 16, 2010 5:08 PM Subject: Re: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user perspective. > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction. We don't > need to decide if it is _the_ direction. Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory. If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering. This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works. It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon Aug 16 11:27:32 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 16 Aug 2010 10:27:32 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > > > > > Catering to platform specific APIs is a net loss in my > > opinion but maybe > > it works. It moves the platform independance > > responsibility to rxtx in > > the end. I don't see that we have the resources to do this > > more than > > once. > > I looked at JNA briefly, and I don't like going in that direction. > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 16:05:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 16:05:21 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Mon, 16 Aug 2010, Adrian Crum wrote: > --- On Sun, 8/15/10, Trent Jarvi wrote: >> On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >> >>>>> I would also suggest that by using JNA we >> could get rid of the C code >>>>> altogether, making (no pun intended) building >> the code a trivial effort. >>> >>>> Anything that would make it easier to deploy and >> have less reliance on native >>>> code would be greatly appreciated from a >> end-user?perspective.? >>> >>> With JNA all the interface code is pure Java and JNA >> itself is a single .jar >>> file, so deployment is very simple. No platform >> specific native libraries, >>> DLLs etc etc. All you need is the jna.jar file in your >> classpath and >>> that is it. Or package the jna.jar with your Java >> application code and >>> you have a single cross platform executable solution. >>> >>> For an example on how easy it is to call standard C >> library printf from Java >>> in Mac OS X / Linux / Windows see: >>> >>> http://en.wikipedia.org/wiki/Java_Native_Access >>> >>> For details see the project home at: >>> >>> https://jna.dev.java.net/ >>> >>> >> >> From the perspective of rxtx this is another possible >> direction.? We don't >> need to decide if it is _the_ direction.? Don't try to >> load the wagon with >> developers, show its the way to go. >> >> If you like, I can give cvs access and people can go nuts >> in a JNA >> directory.? If it becomes obvious that we should do >> that, great. >> >> The solution and problems presented by JNA are an >> interesting area I've >> been pondering.? This falls more along the lines of >> catering to some >> platform specific APIs but using as little of them as >> possible. >> >> Catering to platform specific APIs is a net loss in my >> opinion but maybe >> it works.? It moves the platform independance >> responsibility to rxtx in >> the end. I don't see that we have the resources to do this >> more than >> once. > > I looked at JNA briefly, and I don't like going in that direction. > >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > The termios (basically all the serial specific stuff) calls are POSIX calls. Right now, the API exists and is supported on windows but not all versions. Microsoft has started including the POSIX layer in their servers, if they do it for all their systems, the funky code in rxtx that provices ioctl/termios/... for windows could go away with a few minor adjustments. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:20:09 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:20:09 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi? Tried to find some documentation or tutorial but couldn't ...so what is the difference / advantage? Does it work on all the platforms where JNA works? br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:30:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:30:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > I looked at JNA briefly, and I don't like going in that direction. > Ok, but it would be helpful if you elaborated a bit... the point about JNA is ease of deployment and development. In my experience the simple task of compiling C as you need to do with JNI can be a major headache especially for user and in open source projects users are often told to 'grab the latest CVS and compile' which more often than not does not work out of the box. >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > I too did not get what this means...how accessing the serial port from Java with a few JNA calls would make rxtx become POSIX. From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:43:48 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:43:48 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: don't like going in that direction. >> >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their > servers, if they do it for all their systems, the funky code in rxtx > that provices ioctl/termios/... for windows could go away with a few > minor adjustments. > > -- > Trent Jarvi > tjarvi at qbang.org I may have lost the thread a bit but ... maybe that is because I have not looked into the rxtx code. From adrian.crum at yahoo.com Tue Aug 17 00:56:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 23:56:47 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <333325.87714.qm@web63106.mail.re1.yahoo.com> --- On Mon, 8/16/10, Kustaa Nyholm wrote: > > I looked at JNA briefly, and I don't like going in > that direction. > > > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. I don't see where it makes development or deployment any easier. > In my experience the simple task of compiling C as you need > to do with > JNI can be a major headache especially for user and in open > source > projects users are often told to 'grab the latest CVS and > compile' > which more often than not does not work out of the box. Are you experiencing that headache with this project in particular? I haven't used C in years, and I was able to download the RXTX repo, set up my dev environment and get it to compile within a few hours. > >> The original idea for rxtx was to target POSIX not > to > >> become POSIX. > > > > Could you elaborate on that more? How does POSIX > relate to RXTX? > > > > I too did not get what this means...how accessing the > serial port > from Java with a few JNA calls would make rxtx become > POSIX. What Trent is saying is that RXTX interacts with port hardware using the POSIX API: Java -> JNI -> RXTX native code -> POSIX API -> port hardware -Adrian From george.dma at gmail.com Tue Aug 17 00:59:22 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 09:59:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Tue, Aug 17, 2010 at 9:30 AM, Kustaa Nyholm wrote: > >> >> I looked at JNA briefly, and I don't like going in that direction. >> > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. > In my opinion JNA is just a proxy pattern for gluing the native libs to your java code. Lets say you used JNA with rxtx, you would still needed to code, compile and debug the windows DLL and the linux SO files anyways. In fact this may make development a bit harder. Already in rxtx they have the java side of the code and the C (windows and linux) side of it. And in the middle are the JNI classes that bind things together. When you deploy the jar files, you add them to your class path. JNA may make that part a tad simpler but not by a mile. Using JNA still means you have to work with the native code and they might as well just keep things the way they are. Perhaps organize it more or something. See these references http://today.java.net/article/2009/11/11/simplify-native-code-access-jna https://jna.dev.java.net/ >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > I too did not get what this means...how accessing the serial port > from Java with a few JNA calls would make rxtx become POSIX. > I believe that sounded a bit odd too. rxtx is "targeting" POSIX and Win32 and others anyways. They write the native libs that access the underlying OS to communicate with the serial/parallel ports. So either way with or without JNA you still have to compile,code,debug the native stuff. Providing the native source files is better as you can compile and run it. If you had JNA (I assume) you'd need to compile, package the native lives into some JNA jar package then test it. Trent said > If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. Why not, if it proves to work then great. If not then it doesn't harm anything. -- George H george.dma at gmail.com From mariusz.dec at gmail.com Tue Aug 17 01:25:00 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 09:25:00 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> ----- Original Message ----- From: "George H" To: Sent: Tuesday, August 17, 2010 8:59 AM > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. I agree - 300 percent :). When I am using RXTX in W/M/L environment with JNI, I suppose that peoples like Trent knows many, many more than me about NATIVE W/M/L/.... calls. I don't want to learn about all-platforms-native-calls because rest of the applications need a lot of time as well!!! This is why Java was developed...., I think... WE (programmers) have currently so many things to remember that ready for use JNI like RXTX is very usefull. The important thing is good planning if computing power of the machine with our aplication will be enough for OS over OS (Java over W/M/L/.....). Regards Mariusz From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:34:51 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:34:51 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <333325.87714.qm@web63106.mail.re1.yahoo.com> Message-ID: > > I don't see where it makes development or deployment any easier. > > Are you experiencing that headache with this project in particular? Yes, a few years ago I was able to pull the CVS version and get it to compile on my Mac with just minor adjustments. A year and two Mac's later last year I could not not. I now rely on a precompiled binary and hope it won't break. And no, I have not tried the latest CVS with my latest Mac as I have other things to do than trying to figure out why this or that configure/make/install fails. > I haven't > used C in years, and I was able to download the RXTX repo, set up my dev > environment and get it to compile within a few hours. A few hours?! If it was based on JNA it should be minutes. And that few hours was just for your platform (what ever it is), how about doing this for all the platforms? N times a few hours. > > What Trent is saying is that RXTX interacts with port hardware using the POSIX > API: > > Java -> JNI -> RXTX native code -> POSIX API -> port hardware > > -Adrian > Thanks, got it now. br Kusti From lucio at sulweb.org Tue Aug 17 01:39:25 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 09:39:25 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <201008170939.25390.lucio@sulweb.org> August 17 2010 08:59:22, George H wrote: > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. I believe it is more effectively used to glue your java code to *others* native libs (e.g. host OS native libs). > Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. The point is, with JNA you don't need to write native code in C anymore, you write it in java and call OS native libs directly from java when needed with runtime lookup of function pointers. This way compilation is easier for users of the rxtx library. I agree debugging and developing rxtx can become a little harder. That said, I've no practical JNA knowledge, so it's more than likely that I miss some important JNA details. August 17 2010 08:43:48, Kustaa Nyholm wrote: > What I was suggesting was to just do the low level access to the OS using > JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that > can easily be coded in Java. Exactly what I mean. August 17 2010 08:56:47, Adrian Crum wrote: > Are you experiencing that headache with this project in particular? I > haven't used C in years, and I was able to download the RXTX repo, set up > my dev environment and get it to compile within a few hours. *A FEW HOURS*? Such a time to setup a build environment is way too much for most rxtx users (non-rxtx-developers), especially since it is a very commonly suggested way to grab the best rxtx code. A library user expects to be able to download it and use it in a few seconds, not hours. For example I need just now to grab the sources only for the crashes problem, and "a few hours", assuming all goes well, seem a bit too much since I don't plan to become a rxtx developer. I think JNA could make this situation better. My 2 cents, Lucio. From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:44:43 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:44:43 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. No, not correct. With JNA you don't need a C compiler and you don't need to compile any DLL/SOs. Did you check the example in the wikipedia about calling printf? Absolutely no C-code involved. If and when your favorite OS provides an API you can call from C and link to your application, using JNA you just write a Java interface that conforms to the calling convention and point it to the system library and that is it. > > Already in rxtx they have the java side of the code and the C (windows > and linux) side of it. And in the middle are the JNI classes that bind > things together. I was suggesting, in the context of rewriting things, getting rid of the C side of things. > When you deploy the jar files, you add them to your > class path. JNA may make that part a tad simpler but not by a mile. If you have precompiled (rxtx) libraries available, there is not a big difference, but if you are *developing* a cross platform library there is world of difference in setting up the tool chains for all the platforms and keeping them up-to-date. And like I said, user of open source libraries too often have to compile them. > > Using JNA still means you have to work with the native code and they > might as well just keep things the way they are. Perhaps organize it > more or something. > Like I said, my comments were in the context of rewriting things. If the current code base is just tweaked or improved, naturally there is no point in upsetting things by introducing anything to replace JNI, but if the code is rewritten, then I think it would make sense to seriously consider getting rid of the C-side of things and use JNA. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:54:25 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:54:25 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > I agree - 300 percent :). Agree with what? Agree with the wrong conclusion that you still need DLL and/or SO files anyway? Agree with the misguided conclusion that when you don't need to maintain a C compiler tool chain and don't have to debug both C and Java the development is a bit harder? > When I am using RXTX in W/M/L environment with JNI, I suppose that peoples > like Trent knows many, many more than me about NATIVE W/M/L/.... calls. > I don't want to learn about all-platforms-native-calls because rest of the > applications need a lot of time as well!!! The whole point of RXTX is of course that you don't need to know these things. So JNA versus JNI should be mostly irrelevant to you. That is why I don't understand why you care what RXTX does internally and don't understand why you agree 300% with an opinion that dismisses JNA in favor of JNI based on disinformation and out of context. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 02:01:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 11:01:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <201008170939.25390.lucio@sulweb.org> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. > > I believe it is more effectively used to glue your java code to *others* > native > libs (e.g. host OS native libs). Exactly! > >> Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > The point is, with JNA you don't need to write native code in C anymore, you > write it in java and call OS native libs directly from java when needed with > runtime lookup of function pointers. This way compilation is easier for users > of the rxtx library. I agree debugging and developing rxtx can become a little > harder. That said, I've no practical JNA knowledge, so it's more than likely > that I miss some important JNA details. I have practical knowledge of both JNA and JNI on Linux/Windows/Mac setting using JNA things are so much easier. And when we are talking about calls to native system API, I think debugging is also easier because you don't realy want to step into system calls anyway so all you debugging is on the Java side. There is no C side to debug, hence no need to debug that and as a bonus, provided you pass sensible values to the system calls there is nothing that can crash as Java programs just throw exceptions which are easy to catch, handle and debug. > > August 17 2010 08:43:48, Kustaa Nyholm wrote: >> What I was suggesting was to just do the low level access to the OS using >> JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that >> can easily be coded in Java. > > Exactly what I mean. We are so much on the same page with this! > > August 17 2010 08:56:47, Adrian Crum wrote: >> Are you experiencing that headache with this project in particular? I >> haven't used C in years, and I was able to download the RXTX repo, set up >> my dev environment and get it to compile within a few hours. > > *A FEW HOURS*? Such a time to setup a build environment is way too much for > most rxtx users (non-rxtx-developers), especially since it is a very commonly > suggested way to grab the best rxtx code. A library user expects to be able to > download it and use it in a few seconds, not hours. For example I need just > now to grab the sources only for the crashes problem, and "a few hours", > assuming all goes well, seem a bit too much since I don't plan to become a > rxtx developer. > Could not agree with you more. > I think JNA could make this situation better. I'm sure it would. br Kusti From george.dma at gmail.com Tue Aug 17 02:20:13 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 11:20:13 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Tue, Aug 17, 2010 at 10:44 AM, Kustaa Nyholm wrote: > >> >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. > > No, not correct. With JNA you don't need a C compiler and you don't need > to compile any DLL/SOs. > > Did you check the example in the wikipedia about calling printf? > > Absolutely no C-code involved. > > If and when your favorite OS provides an API you can call from C and > link to your application, using JNA you just write a Java interface > that conforms to the calling convention and point it to the system > library and that is it. > I have seen the JNA project and I do agree that it creates the interface for you for calling native libraries. It works great if you are just looking to call a method from a native API. I've done this before using JNI and in most cases I've seen using JNA for me would be good. But the problem I see is when I look at the rxtx C source code. I see a lot more than that, there is a quite a bulk of work that is being done. I was seeing using JNA as the abstraction layer between the rxtx java code and the rxtx native code. To which if that was the case then JNA would be a bit useless. I guess I fell into that trap by not explaining too much. So for that I do apologize. However when you mention a complete re-write, this is where things get interesting. This is also where I agree with Trent on making a JNA directory and letting devs go wild and see if this works. I assume they'd have to use JNA to create the access to the native libs. Then just test it to see if everything works. Then I'd assume they'd have to scan the current native code and see what extra calculations and algorithms are being done and apply them in the java code. This part I guess would be time consuming, so it will take effort and time to migrate fully with JNA. I am not the lead of the project and I believe creating a JNA dir for research, dev and testing is a good idea. It helps current rxtx devs to carry on and new devs to re-write portions of the project to use JNA. Then it depends on the project lead as to how the project will evolve. Effectively I would like to hear more technical details from lead devs on this issue, perhaps they can write out the pros and cons on the development side and on the deployment side. This is why I am not really against but not really for JNA. I am for people testing it out, definitely. I am also for keeping what currently works. From mariusz.dec at gmail.com Tue Aug 17 02:31:04 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 10:31:04 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: Message-ID: <8129C8E0DD78429D8E8350B8E5474DC7@mdam2> ----- Original Message ----- From: "Kustaa Nyholm" >>> files anyways. In fact this may make development a bit harder. >> >> I agree - 300 percent :). > > Agree with what? Take it easy Kusti :). I was thinking that this is harder because of looking for native calls structure. For example - I know where and how to look for Windows data about it, but I don't know today where to look for it in Linux/Macintosh. I know google, but what for loosing time if I don't think I will be native-programmer in L/M/... > > > The whole point of RXTX is of course that you don't need to know these > things. So JNA versus JNI should be mostly irrelevant to you. > > That is why I don't understand why you care what RXTX does internally and > don't understand why you agree 300% with an opinion that dismisses JNA in > favor of JNI based on disinformation and out of context. > > br Kusti > Ok, in wide context general change of RXTX to JNA looks not bad, if SOMEBOEDY will do it and test it. But if RXTX (as is today) works ....? In our country peoples saying: - Better is the enemy of the good.... When I was writing this post, George H has wriiten about time needed for Java, if Java will do some things as RXTX-C part. So I do not need to rewrite nothing about this very important point :). Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From iqzw2r602 at sneakemail.com Tue Aug 17 02:55:24 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 18:55:24 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <4850-1282035324-678892@sneakemail.com> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their servers, > if they do it for all their systems, the funky code in rxtx that provices > ioctl/termios/... for windows could go away with a few minor adjustments. > That sounds like an appealing option for a rxtx 2.3; reducing complexity is always good for code that should live long. I wonder if that's the way to go for 3.0 though. From first hand experience, the slim direct OS wrapper approach (to have native Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much easier to debug and maintain, because you will not have to debug native code any more. And you could convert the C that calls read() etc. to Java in a snap that way (the Java code will be almost exactly the same with these wrappers!) The solution on Windows can be to either 1) convert your win32 termios wrappers to Java as well, and make Java-converted SerialImp.c code call them. The Java termios can then call win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). 2) Have separate java implementations for a POSIX serial port and a Windows serial port, both in Java, that access the OS via the mentioned slim wrappers. That's the approach that I used for jpathwatch, which has worked very well for me. Option 1) is probably the least work, option 2) the more sustainable and likely to perform better. You can actually do them both in order, because you can later migrate from 1) to 2). And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; they're stable and tested, and exist for Unix and Windows. All that needs to be done is to follow the pattern and add the OS functions you're missing, which I'm happy to assist with. Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Aug 17 03:15:34 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 12:15:34 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically all the serial specific stuff) calls are POSIX >> calls.. ?Right now, the API exists and is supported on windows but not all >> versions. ?Microsoft has started including the POSIX layer in their servers, >> if they do it for all their systems, the funky code in rxtx that provices >> ioctl/termios/... for windows could go away with a few minor adjustments. > > That sounds like an appealing option for a rxtx 2.3; reducing complexity is > always good for code that should live long. > > I wonder if that's the way to go for 3.0 though. From first hand experience, > the slim direct OS wrapper approach (to have native Unix.read(), > Unix.select(), Unix.open(), etc. java methods) is much easier to debug and > maintain, because you will not have to debug native code any more. And you > could convert the C that calls read() etc. to Java in a snap that way (the > Java code will be almost exactly the same with these wrappers!) > > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then call > win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). > 2) Have separate java implementations for a POSIX serial port and a Windows > serial port, both in Java, that access the OS via the mentioned slim > wrappers. That's the approach that I used for jpathwatch, which has worked > very well for me. > > Option 1) is probably the least work, option 2) the more sustainable and > likely to perform better. You can actually do them both in order, because > you can later migrate from 1) to 2). > > And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; > they're stable and tested, and exist for Unix and Windows. All that needs to > be done is to follow the pattern and add the OS functions you're missing, > which I'm happy to assist with. > > Cheers, > > Uwe > Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Tue Aug 17 06:14:42 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 22:14:42 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <16747-1282047283-672654@sneakemail.com> People post problems on the forums mainly, but youre right, its time to take the bug tracker online. So I just did. If you are look for past issues, look on the forums. Cheers, Uwe On 17/08/2010 7:23 PM, "George H george.dma-at-gmail.com |rxtx.org mailing list/Example Allow|" wrote: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically ... Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qban... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyon at docjava.com Tue Aug 17 06:28:29 2010 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Aug 2010 08:28:29 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: Hi All, Has anyone tried using JNA to gain access to web cams? Thanks! - Doug P.S. Quicktime for Java could do this, but Apple killed it. From Kustaa.Nyholm at planmeca.com Tue Aug 17 06:43:11 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 15:43:11 +0300 Subject: [Rxtx] JNA 4 web cams In-Reply-To: Message-ID: > Has anyone tried using JNA to gain access to web cams? Not a web cam but one of these: http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 took me about half an hour to convert the C-headers to a JNA interface and it worked no problem. br Kusti From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From msemtd at googlemail.com Thu Aug 12 04:59:43 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 11:59:43 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Message-ID: On 12 August 2010 10:33, M.Dec-GM wrote: > When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. > Because of this observation I have thought what may be faster as a normal message events queue. > Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! > Basing on this idea I have decide to NOT use serial events. > Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. > Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. > This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Hi Mariusz, That's a very effective and creative approach. You could consider a technique from the Java concurrency API, such as a LinkedBlockingDeque to share messages with the main application. That is my usual approach -- I will be posting a working example on the wiki when I have time. If you put your code on the wiki also then the users will have more examples to work from. Regards, Michael. From psuhas at gmail.com Thu Aug 12 14:57:52 2010 From: psuhas at gmail.com (Suhas Pharkute) Date: Thu, 12 Aug 2010 14:57:52 -0600 Subject: [Rxtx] Error in Java Message-ID: Hi, I am getting an error when I load an applet in xulrunner app (mozilla) java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: no suitable image found. Did find: /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper When I did my research it shows me that I need to use -d32 option while launching JVM. I am not sure how to do that? Can some one please help. Thank you, Suhas Pharkute (805) 229-1450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 00:37:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:37:39 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >>> I would also suggest that by using JNA we could get rid of the C code >>> altogether, making (no pun intended) building the code a trivial effort. > >> Anything that would make it easier to deploy and have less reliance on native >> code would be greatly appreciated from a end-user?perspective.? > > With JNA all the interface code is pure Java and JNA itself is a single .jar > file, so deployment is very simple. No platform specific native libraries, > DLLs etc etc. All you need is the jna.jar file in your classpath and > that is it. Or package the jna.jar with your Java application code and > you have a single cross platform executable solution. > > For an example on how easy it is to call standard C library printf from Java > in Mac OS X / Linux / Windows see: > > http://en.wikipedia.org/wiki/Java_Native_Access > > For details see the project home at: > > https://jna.dev.java.net/ > > >From the perspective of rxtx this is another possible direction. We don't need to decide if it is _the_ direction. Don't try to load the wagon with developers, show its the way to go. If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. The solution and problems presented by JNA are an interesting area I've been pondering. This falls more along the lines of catering to some platform specific APIs but using as little of them as possible. Catering to platform specific APIs is a net loss in my opinion but maybe it works. It moves the platform independance responsibility to rxtx in the end. I don't see that we have the resources to do this more than once. The original idea for rxtx was to target POSIX not to become POSIX. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Aug 16 00:47:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:47:39 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > >> The attached patch is cumulative - it includes the previous patches. >> >> A number of changes to make RXTXCommDriver and CommPortIdentifier >> thread-safe: >> >> 1. Converted CommPortIdentifier linked list to a HashMap and moved it to >> RXTXCommDriver, put RXTXCommDriver in control of the Map and have >> CommPortIdentifier delegate method calls to RXTXCommDriver. >> >> There was a flaw in the design. One thread could be traversing the linked >> list while another thread is modifying it - causing unpredictable results >> or NPEs. >> >> 2. Synchronized access to the listener Vector in CommPortIdentifier. >> >> 3. Fixed the open method in CommPortIdentifier. Even though the method >> included synchronized blocks, it was not thread-safe - another thread could >> change the object's state in the gaps between the synchronized blocks. >> >> This will be my last patch for now. If these changes make it into the >> project, then I will submit more. >> > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the changes this week. > I'll let you know if I find anything. > I'm just following up to let you know this isnt sitting on a dusty shelf. The patches look fine. I have a meeting Tuesday about testing them. There is a possibility to streamline the process on my end so I'm taking the time to do it. Basically, I use rxtx at work as well and have access to a build and test system that covers the main platforms and has tests used since ~2000 for rxtx. I suspect I'll be able to push this through a set of nontrivial tests Wednesday. Maybe we can get some code coverage numbers as a bonus. I'm also looking at making the tests available outside of that harness. Its something I'm in favor of but takes more than a Tuesday meeting :) -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 16 08:32:25 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 07:32:25 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <54491.35492.qm@web63107.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > > > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > >> The attached patch is cumulative - it includes the > previous patches. > >> > >> A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > >> > >> 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > >> > >> There was a flaw in the design. One thread could > be traversing the linked list while another thread is > modifying it - causing unpredictable results or NPEs. > >> > >> 2. Synchronized access to the listener Vector in > CommPortIdentifier. > >> > >> 3. Fixed the open method in CommPortIdentifier. > Even though the method included synchronized blocks, it was > not thread-safe - another thread could change the object's > state in the gaps between the synchronized blocks. > >> > >> This will be my last patch for now. If these > changes make it into the project, then I will submit more. > >> > > > > Thanks Adrian, > > > > I'll be reviewing these and running a test suite on > the changes this week. I'll let you know if I find > anything. > > > > I'm just following up to let you know this isnt sitting on > a dusty shelf. > > The patches look fine.? I have a meeting Tuesday about > testing them. There is a possibility to streamline the > process on my end so I'm taking the time to do it.? > Basically, I use rxtx at work as well and have access to a > build and test system that covers the main platforms and has > tests used since ~2000 for rxtx. > > I suspect I'll be able to push this through a set of > nontrivial tests Wednesday.? Maybe we can get some code > coverage numbers as a bonus. > > I'm also looking at making the tests available outside of > that harness. Its something I'm in favor of but takes more > than a Tuesday meeting :) You must have missed my previous reply. Don't worry about that patch - I have abandoned work on 2.x in favor of a rewrite. I will have a formal V3 proposal ready in about a week. The first patch should get committed though - the one that fixes the properties file issues. In fact, that should be backported to previous versions. -Adrian From adrian.crum at yahoo.com Mon Aug 16 09:08:55 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 08:08:55 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <370266.35744.qm@web63104.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user?perspective.? > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction.? We don't > need to decide if it is _the_ direction.? Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory.? If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering.? This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works.? It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian From mariusz.dec at gmail.com Mon Aug 16 11:26:43 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Mon, 16 Aug 2010 19:26:43 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <0C4CFD3F08FE4FCCBD2F297DB56928EB@mdam2> Hi all, A bit Off Topic.... And we are going "back to the future" :))). Java was developed to be platform independent. Very nice idea but.... who knows Operating Systems rules, know what about I am thinking. Finally - everybody is looking how to do Java platform dependend because of ... performance. Surprise or not??? Ok - this example from Wiki gives multiplatform code on the higher level than conditionals in C code and THIS IS a very big step ahead comparing to early 90'ths... I am not Java enemy, but Java's overhead (in fact OS over OS) should be very carefully analysed before use Java on the small/relative slow platforms. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Monday, August 16, 2010 5:08 PM Subject: Re: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user perspective. > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction. We don't > need to decide if it is _the_ direction. Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory. If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering. This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works. It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon Aug 16 11:27:32 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 16 Aug 2010 10:27:32 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > > > > > Catering to platform specific APIs is a net loss in my > > opinion but maybe > > it works. It moves the platform independance > > responsibility to rxtx in > > the end. I don't see that we have the resources to do this > > more than > > once. > > I looked at JNA briefly, and I don't like going in that direction. > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 16:05:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 16:05:21 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Mon, 16 Aug 2010, Adrian Crum wrote: > --- On Sun, 8/15/10, Trent Jarvi wrote: >> On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >> >>>>> I would also suggest that by using JNA we >> could get rid of the C code >>>>> altogether, making (no pun intended) building >> the code a trivial effort. >>> >>>> Anything that would make it easier to deploy and >> have less reliance on native >>>> code would be greatly appreciated from a >> end-user?perspective.? >>> >>> With JNA all the interface code is pure Java and JNA >> itself is a single .jar >>> file, so deployment is very simple. No platform >> specific native libraries, >>> DLLs etc etc. All you need is the jna.jar file in your >> classpath and >>> that is it. Or package the jna.jar with your Java >> application code and >>> you have a single cross platform executable solution. >>> >>> For an example on how easy it is to call standard C >> library printf from Java >>> in Mac OS X / Linux / Windows see: >>> >>> http://en.wikipedia.org/wiki/Java_Native_Access >>> >>> For details see the project home at: >>> >>> https://jna.dev.java.net/ >>> >>> >> >> From the perspective of rxtx this is another possible >> direction.? We don't >> need to decide if it is _the_ direction.? Don't try to >> load the wagon with >> developers, show its the way to go. >> >> If you like, I can give cvs access and people can go nuts >> in a JNA >> directory.? If it becomes obvious that we should do >> that, great. >> >> The solution and problems presented by JNA are an >> interesting area I've >> been pondering.? This falls more along the lines of >> catering to some >> platform specific APIs but using as little of them as >> possible. >> >> Catering to platform specific APIs is a net loss in my >> opinion but maybe >> it works.? It moves the platform independance >> responsibility to rxtx in >> the end. I don't see that we have the resources to do this >> more than >> once. > > I looked at JNA briefly, and I don't like going in that direction. > >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > The termios (basically all the serial specific stuff) calls are POSIX calls. Right now, the API exists and is supported on windows but not all versions. Microsoft has started including the POSIX layer in their servers, if they do it for all their systems, the funky code in rxtx that provices ioctl/termios/... for windows could go away with a few minor adjustments. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:20:09 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:20:09 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi? Tried to find some documentation or tutorial but couldn't ...so what is the difference / advantage? Does it work on all the platforms where JNA works? br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:30:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:30:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > I looked at JNA briefly, and I don't like going in that direction. > Ok, but it would be helpful if you elaborated a bit... the point about JNA is ease of deployment and development. In my experience the simple task of compiling C as you need to do with JNI can be a major headache especially for user and in open source projects users are often told to 'grab the latest CVS and compile' which more often than not does not work out of the box. >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > I too did not get what this means...how accessing the serial port from Java with a few JNA calls would make rxtx become POSIX. >From the users points of view expectation for rxtx is that it is the replacement for Sun's abandoned javacomm. And the expectation for javacomm is that we can access the serial port from Java in a platform independent manner. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:43:48 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:43:48 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: don't like going in that direction. >> >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their > servers, if they do it for all their systems, the funky code in rxtx > that provices ioctl/termios/... for windows could go away with a few > minor adjustments. > > -- > Trent Jarvi > tjarvi at qbang.org I may have lost the thread a bit but ... maybe that is because I have not looked into the rxtx code. >From above I gather that rxtx is coded so that it works on POSIX and on Windows there is some C code that makes Windows look more or less like POSIX, is this correct? On the face of it, that looks very reasonable. What I was suggesting was to just do the low level access to the OS using JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that can easily be coded in Java. The ease of development, maintenance and deployment is so much better with JNA than with JNI. All the developer has to do is to include the jna.jar in the classpath and create a few classes/interfaces in Java. No C compiler and the associated pain in sight. The same goes for the users of rxtx (if it takes the JNA route) and even for the users of those applications using rxtx. br Kusti From adrian.crum at yahoo.com Tue Aug 17 00:56:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 23:56:47 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <333325.87714.qm@web63106.mail.re1.yahoo.com> --- On Mon, 8/16/10, Kustaa Nyholm wrote: > > I looked at JNA briefly, and I don't like going in > that direction. > > > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. I don't see where it makes development or deployment any easier. > In my experience the simple task of compiling C as you need > to do with > JNI can be a major headache especially for user and in open > source > projects users are often told to 'grab the latest CVS and > compile' > which more often than not does not work out of the box. Are you experiencing that headache with this project in particular? I haven't used C in years, and I was able to download the RXTX repo, set up my dev environment and get it to compile within a few hours. > >> The original idea for rxtx was to target POSIX not > to > >> become POSIX. > > > > Could you elaborate on that more? How does POSIX > relate to RXTX? > > > > I too did not get what this means...how accessing the > serial port > from Java with a few JNA calls would make rxtx become > POSIX. What Trent is saying is that RXTX interacts with port hardware using the POSIX API: Java -> JNI -> RXTX native code -> POSIX API -> port hardware -Adrian From george.dma at gmail.com Tue Aug 17 00:59:22 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 09:59:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Tue, Aug 17, 2010 at 9:30 AM, Kustaa Nyholm wrote: > >> >> I looked at JNA briefly, and I don't like going in that direction. >> > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. > In my opinion JNA is just a proxy pattern for gluing the native libs to your java code. Lets say you used JNA with rxtx, you would still needed to code, compile and debug the windows DLL and the linux SO files anyways. In fact this may make development a bit harder. Already in rxtx they have the java side of the code and the C (windows and linux) side of it. And in the middle are the JNI classes that bind things together. When you deploy the jar files, you add them to your class path. JNA may make that part a tad simpler but not by a mile. Using JNA still means you have to work with the native code and they might as well just keep things the way they are. Perhaps organize it more or something. See these references http://today.java.net/article/2009/11/11/simplify-native-code-access-jna https://jna.dev.java.net/ >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > I too did not get what this means...how accessing the serial port > from Java with a few JNA calls would make rxtx become POSIX. > I believe that sounded a bit odd too. rxtx is "targeting" POSIX and Win32 and others anyways. They write the native libs that access the underlying OS to communicate with the serial/parallel ports. So either way with or without JNA you still have to compile,code,debug the native stuff. Providing the native source files is better as you can compile and run it. If you had JNA (I assume) you'd need to compile, package the native lives into some JNA jar package then test it. Trent said > If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. Why not, if it proves to work then great. If not then it doesn't harm anything. -- George H george.dma at gmail.com From mariusz.dec at gmail.com Tue Aug 17 01:25:00 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 09:25:00 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> ----- Original Message ----- From: "George H" To: Sent: Tuesday, August 17, 2010 8:59 AM > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. I agree - 300 percent :). When I am using RXTX in W/M/L environment with JNI, I suppose that peoples like Trent knows many, many more than me about NATIVE W/M/L/.... calls. I don't want to learn about all-platforms-native-calls because rest of the applications need a lot of time as well!!! This is why Java was developed...., I think... WE (programmers) have currently so many things to remember that ready for use JNI like RXTX is very usefull. The important thing is good planning if computing power of the machine with our aplication will be enough for OS over OS (Java over W/M/L/.....). Regards Mariusz From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:34:51 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:34:51 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <333325.87714.qm@web63106.mail.re1.yahoo.com> Message-ID: > > I don't see where it makes development or deployment any easier. > > Are you experiencing that headache with this project in particular? Yes, a few years ago I was able to pull the CVS version and get it to compile on my Mac with just minor adjustments. A year and two Mac's later last year I could not not. I now rely on a precompiled binary and hope it won't break. And no, I have not tried the latest CVS with my latest Mac as I have other things to do than trying to figure out why this or that configure/make/install fails. > I haven't > used C in years, and I was able to download the RXTX repo, set up my dev > environment and get it to compile within a few hours. A few hours?! If it was based on JNA it should be minutes. And that few hours was just for your platform (what ever it is), how about doing this for all the platforms? N times a few hours. > > What Trent is saying is that RXTX interacts with port hardware using the POSIX > API: > > Java -> JNI -> RXTX native code -> POSIX API -> port hardware > > -Adrian > Thanks, got it now. br Kusti From lucio at sulweb.org Tue Aug 17 01:39:25 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 09:39:25 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <201008170939.25390.lucio@sulweb.org> August 17 2010 08:59:22, George H wrote: > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. I believe it is more effectively used to glue your java code to *others* native libs (e.g. host OS native libs). > Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. The point is, with JNA you don't need to write native code in C anymore, you write it in java and call OS native libs directly from java when needed with runtime lookup of function pointers. This way compilation is easier for users of the rxtx library. I agree debugging and developing rxtx can become a little harder. That said, I've no practical JNA knowledge, so it's more than likely that I miss some important JNA details. August 17 2010 08:43:48, Kustaa Nyholm wrote: > What I was suggesting was to just do the low level access to the OS using > JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that > can easily be coded in Java. Exactly what I mean. August 17 2010 08:56:47, Adrian Crum wrote: > Are you experiencing that headache with this project in particular? I > haven't used C in years, and I was able to download the RXTX repo, set up > my dev environment and get it to compile within a few hours. *A FEW HOURS*? Such a time to setup a build environment is way too much for most rxtx users (non-rxtx-developers), especially since it is a very commonly suggested way to grab the best rxtx code. A library user expects to be able to download it and use it in a few seconds, not hours. For example I need just now to grab the sources only for the crashes problem, and "a few hours", assuming all goes well, seem a bit too much since I don't plan to become a rxtx developer. I think JNA could make this situation better. My 2 cents, Lucio. From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:44:43 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:44:43 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. No, not correct. With JNA you don't need a C compiler and you don't need to compile any DLL/SOs. Did you check the example in the wikipedia about calling printf? Absolutely no C-code involved. If and when your favorite OS provides an API you can call from C and link to your application, using JNA you just write a Java interface that conforms to the calling convention and point it to the system library and that is it. > > Already in rxtx they have the java side of the code and the C (windows > and linux) side of it. And in the middle are the JNI classes that bind > things together. I was suggesting, in the context of rewriting things, getting rid of the C side of things. > When you deploy the jar files, you add them to your > class path. JNA may make that part a tad simpler but not by a mile. If you have precompiled (rxtx) libraries available, there is not a big difference, but if you are *developing* a cross platform library there is world of difference in setting up the tool chains for all the platforms and keeping them up-to-date. And like I said, user of open source libraries too often have to compile them. > > Using JNA still means you have to work with the native code and they > might as well just keep things the way they are. Perhaps organize it > more or something. > Like I said, my comments were in the context of rewriting things. If the current code base is just tweaked or improved, naturally there is no point in upsetting things by introducing anything to replace JNI, but if the code is rewritten, then I think it would make sense to seriously consider getting rid of the C-side of things and use JNA. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:54:25 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:54:25 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > I agree - 300 percent :). Agree with what? Agree with the wrong conclusion that you still need DLL and/or SO files anyway? Agree with the misguided conclusion that when you don't need to maintain a C compiler tool chain and don't have to debug both C and Java the development is a bit harder? > When I am using RXTX in W/M/L environment with JNI, I suppose that peoples > like Trent knows many, many more than me about NATIVE W/M/L/.... calls. > I don't want to learn about all-platforms-native-calls because rest of the > applications need a lot of time as well!!! The whole point of RXTX is of course that you don't need to know these things. So JNA versus JNI should be mostly irrelevant to you. That is why I don't understand why you care what RXTX does internally and don't understand why you agree 300% with an opinion that dismisses JNA in favor of JNI based on disinformation and out of context. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 02:01:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 11:01:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <201008170939.25390.lucio@sulweb.org> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. > > I believe it is more effectively used to glue your java code to *others* > native > libs (e.g. host OS native libs). Exactly! > >> Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > The point is, with JNA you don't need to write native code in C anymore, you > write it in java and call OS native libs directly from java when needed with > runtime lookup of function pointers. This way compilation is easier for users > of the rxtx library. I agree debugging and developing rxtx can become a little > harder. That said, I've no practical JNA knowledge, so it's more than likely > that I miss some important JNA details. I have practical knowledge of both JNA and JNI on Linux/Windows/Mac setting using JNA things are so much easier. And when we are talking about calls to native system API, I think debugging is also easier because you don't realy want to step into system calls anyway so all you debugging is on the Java side. There is no C side to debug, hence no need to debug that and as a bonus, provided you pass sensible values to the system calls there is nothing that can crash as Java programs just throw exceptions which are easy to catch, handle and debug. > > August 17 2010 08:43:48, Kustaa Nyholm wrote: >> What I was suggesting was to just do the low level access to the OS using >> JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that >> can easily be coded in Java. > > Exactly what I mean. We are so much on the same page with this! > > August 17 2010 08:56:47, Adrian Crum wrote: >> Are you experiencing that headache with this project in particular? I >> haven't used C in years, and I was able to download the RXTX repo, set up >> my dev environment and get it to compile within a few hours. > > *A FEW HOURS*? Such a time to setup a build environment is way too much for > most rxtx users (non-rxtx-developers), especially since it is a very commonly > suggested way to grab the best rxtx code. A library user expects to be able to > download it and use it in a few seconds, not hours. For example I need just > now to grab the sources only for the crashes problem, and "a few hours", > assuming all goes well, seem a bit too much since I don't plan to become a > rxtx developer. > Could not agree with you more. > I think JNA could make this situation better. I'm sure it would. br Kusti From george.dma at gmail.com Tue Aug 17 02:20:13 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 11:20:13 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Tue, Aug 17, 2010 at 10:44 AM, Kustaa Nyholm wrote: > >> >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. > > No, not correct. With JNA you don't need a C compiler and you don't need > to compile any DLL/SOs. > > Did you check the example in the wikipedia about calling printf? > > Absolutely no C-code involved. > > If and when your favorite OS provides an API you can call from C and > link to your application, using JNA you just write a Java interface > that conforms to the calling convention and point it to the system > library and that is it. > I have seen the JNA project and I do agree that it creates the interface for you for calling native libraries. It works great if you are just looking to call a method from a native API. I've done this before using JNI and in most cases I've seen using JNA for me would be good. But the problem I see is when I look at the rxtx C source code. I see a lot more than that, there is a quite a bulk of work that is being done. I was seeing using JNA as the abstraction layer between the rxtx java code and the rxtx native code. To which if that was the case then JNA would be a bit useless. I guess I fell into that trap by not explaining too much. So for that I do apologize. However when you mention a complete re-write, this is where things get interesting. This is also where I agree with Trent on making a JNA directory and letting devs go wild and see if this works. I assume they'd have to use JNA to create the access to the native libs. Then just test it to see if everything works. Then I'd assume they'd have to scan the current native code and see what extra calculations and algorithms are being done and apply them in the java code. This part I guess would be time consuming, so it will take effort and time to migrate fully with JNA. I am not the lead of the project and I believe creating a JNA dir for research, dev and testing is a good idea. It helps current rxtx devs to carry on and new devs to re-write portions of the project to use JNA. Then it depends on the project lead as to how the project will evolve. Effectively I would like to hear more technical details from lead devs on this issue, perhaps they can write out the pros and cons on the development side and on the deployment side. This is why I am not really against but not really for JNA. I am for people testing it out, definitely. I am also for keeping what currently works. From mariusz.dec at gmail.com Tue Aug 17 02:31:04 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 10:31:04 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: Message-ID: <8129C8E0DD78429D8E8350B8E5474DC7@mdam2> ----- Original Message ----- From: "Kustaa Nyholm" >>> files anyways. In fact this may make development a bit harder. >> >> I agree - 300 percent :). > > Agree with what? Take it easy Kusti :). I was thinking that this is harder because of looking for native calls structure. For example - I know where and how to look for Windows data about it, but I don't know today where to look for it in Linux/Macintosh. I know google, but what for loosing time if I don't think I will be native-programmer in L/M/... > > > The whole point of RXTX is of course that you don't need to know these > things. So JNA versus JNI should be mostly irrelevant to you. > > That is why I don't understand why you care what RXTX does internally and > don't understand why you agree 300% with an opinion that dismisses JNA in > favor of JNI based on disinformation and out of context. > > br Kusti > Ok, in wide context general change of RXTX to JNA looks not bad, if SOMEBOEDY will do it and test it. But if RXTX (as is today) works ....? In our country peoples saying: - Better is the enemy of the good.... When I was writing this post, George H has wriiten about time needed for Java, if Java will do some things as RXTX-C part. So I do not need to rewrite nothing about this very important point :). Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From iqzw2r602 at sneakemail.com Tue Aug 17 02:55:24 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 18:55:24 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <4850-1282035324-678892@sneakemail.com> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their servers, > if they do it for all their systems, the funky code in rxtx that provices > ioctl/termios/... for windows could go away with a few minor adjustments. > That sounds like an appealing option for a rxtx 2.3; reducing complexity is always good for code that should live long. I wonder if that's the way to go for 3.0 though. From first hand experience, the slim direct OS wrapper approach (to have native Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much easier to debug and maintain, because you will not have to debug native code any more. And you could convert the C that calls read() etc. to Java in a snap that way (the Java code will be almost exactly the same with these wrappers!) The solution on Windows can be to either 1) convert your win32 termios wrappers to Java as well, and make Java-converted SerialImp.c code call them. The Java termios can then call win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). 2) Have separate java implementations for a POSIX serial port and a Windows serial port, both in Java, that access the OS via the mentioned slim wrappers. That's the approach that I used for jpathwatch, which has worked very well for me. Option 1) is probably the least work, option 2) the more sustainable and likely to perform better. You can actually do them both in order, because you can later migrate from 1) to 2). And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; they're stable and tested, and exist for Unix and Windows. All that needs to be done is to follow the pattern and add the OS functions you're missing, which I'm happy to assist with. Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Aug 17 03:15:34 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 12:15:34 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically all the serial specific stuff) calls are POSIX >> calls.. ?Right now, the API exists and is supported on windows but not all >> versions. ?Microsoft has started including the POSIX layer in their servers, >> if they do it for all their systems, the funky code in rxtx that provices >> ioctl/termios/... for windows could go away with a few minor adjustments. > > That sounds like an appealing option for a rxtx 2.3; reducing complexity is > always good for code that should live long. > > I wonder if that's the way to go for 3.0 though. From first hand experience, > the slim direct OS wrapper approach (to have native Unix.read(), > Unix.select(), Unix.open(), etc. java methods) is much easier to debug and > maintain, because you will not have to debug native code any more. And you > could convert the C that calls read() etc. to Java in a snap that way (the > Java code will be almost exactly the same with these wrappers!) > > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then call > win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). > 2) Have separate java implementations for a POSIX serial port and a Windows > serial port, both in Java, that access the OS via the mentioned slim > wrappers. That's the approach that I used for jpathwatch, which has worked > very well for me. > > Option 1) is probably the least work, option 2) the more sustainable and > likely to perform better. You can actually do them both in order, because > you can later migrate from 1) to 2). > > And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; > they're stable and tested, and exist for Unix and Windows. All that needs to > be done is to follow the pattern and add the OS functions you're missing, > which I'm happy to assist with. > > Cheers, > > Uwe > Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Tue Aug 17 06:14:42 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 22:14:42 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <16747-1282047283-672654@sneakemail.com> People post problems on the forums mainly, but youre right, its time to take the bug tracker online. So I just did. If you are look for past issues, look on the forums. Cheers, Uwe On 17/08/2010 7:23 PM, "George H george.dma-at-gmail.com |rxtx.org mailing list/Example Allow|" wrote: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically ... Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qban... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyon at docjava.com Tue Aug 17 06:28:29 2010 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Aug 2010 08:28:29 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: Hi All, Has anyone tried using JNA to gain access to web cams? Thanks! - Doug P.S. Quicktime for Java could do this, but Apple killed it. From Kustaa.Nyholm at planmeca.com Tue Aug 17 06:43:11 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 15:43:11 +0300 Subject: [Rxtx] JNA 4 web cams In-Reply-To: Message-ID: > Has anyone tried using JNA to gain access to web cams? Not a web cam but one of these: http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 took me about half an hour to convert the C-headers to a JNA interface and it worked no problem. br Kusti From Steffen.DETTMER at ingenico.com Tue Aug 17 08:09:44 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:09:44 +0200 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: <20100817140944.GA6209@elberon.bln.de.ingenico.com> (OT) * Trent Jarvi wrote on Thu, Aug 05, 2010 at 14:40 -0600: > Some people like it > http://www.metasystema.net/essays/reply-to.html > Some people don't > http://www.unicom.com/pw/reply-to-harmful.html I think both articles are at least around ten years old and I'm afraid the situation still is unchanged, unfortunately. MUAs with proper support of list reply functions, as far as I know, still are rather an exception than the rule - especially webmailers won't offer such a functionality and may not even support any kind of Plug-In that could help (as far as I know, which is very limited). I'm almost sure that even on the latest state-of-the-art hyper-pro-gold "iPhone" clone super device it won't work... Web 2.0, Flash and AJAX - but no mailinglists. Years ago I always was strongly against reply-to munging, because it overwrites the Reply-To: which should be in my authority and invites to accidently to reply to the list instead to the author, but nowadays I see so many problems with daily mails (such as that 95% of the people don't quote well but write 95% of the mails to me etc.), that this one doesn't count much any longer :) Sorry, could not resist, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Aug 17 08:18:42 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:18:42 +0200 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <20100817141842.GB6209@elberon.bln.de.ingenico.com> (OT) Hi Adrian, is it intended to mail to the list to all your postings? I pressed `reply' (not `reply to all'), but since reply-to field asks me to reply the list, so I do :) SCNR. * Adrian Crum wrote on Thu, Aug 05, 2010 at 14:31 -0700: > I'm the former. ;-) Replying to this list will be inconvenient > if I have to keep C&P the ml address in the To: field. I am sure you could find a mail client that makes it still inconvenient... (in other words, Yahoo etc. should be bothered to add this reasonable function) Usually the problem is not copying the ML address, because `reply to all' should set/keep it, but to remove the Authors address to avoid that he gets the mail twice. If you do not use `reply to all' but expect that you reply to all, I think then it is an operating error. SCNR. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From damorales at gmail.com Tue Aug 17 08:25:16 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 17 Aug 2010 10:25:16 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: very interesting ... right now i use v4l4j to use web cams in java apps, but only works on Linux (which is not a problem for me xD) Greetings !! 2010/8/17 Kustaa Nyholm > > > Has anyone tried using JNA to gain access to web cams? > > Not a web cam but one of these: > > > http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 > > took me about half an hour to convert the C-headers to a JNA interface and > it worked no problem. > > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Aug 17 08:55:36 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:55:36 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <20100817145536.GC6209@elberon.bln.de.ingenico.com> Hi, quite an interesting discussion. In short, I think I like the JNI approach as done by rxtx. It uses native code to handle the native platform specifics. It can use defines and whatever is needed to make it work even on un*x systems which may have problems in termios or other implementations. As far as I know, this is common and implementing serial I/O portable and correctly even today still is a major challenge - best done in C (or C++). * iqzw2r602 at sneakemail.com wrote on Tue, Aug 17, 2010 at 18:55 +1000: > > The termios (basically all the serial specific stuff) calls are > > POSIX calls.. Right now, the API exists and is supported on > > windows but not all versions. Microsoft has started including the > > POSIX layer in their servers, if they do it for all their systems, > > the funky code in rxtx that provices ioctl/termios/... for windows > > could go away with a few minor adjustments. So the Windows termios implementation is really usable? We have some C implementations and found it not fully be portable even across different linux versions - I guess, other un*x systems will be even more different... Personally, I think Javas InputStream/OutputStream approach is not suited for communications. A core problem is the missing timeout support (boolean avialable(long timeout)) and that bidirectional I/O might be tricky (to do without multithreading and without polling), because there is not `available_or_ready_to_write'. > That sounds like an appealing option for a rxtx 2.3; reducing > complexity is always good for code that should live long. > I wonder if that's the way to go for 3.0 though. From first hand > experience, the slim direct OS wrapper approach (to have native > Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much > easier to debug and maintain, because you will not have to debug > native code any more. But what for? I understand that when using JNA and handling the platform specifics in Java code, no native lib has to be deployed, which can make deployment easier, ok. But why should it be easier/faster/better to implement low level communications in Java than in C? Looping around read/write controlled by select or termios IMHO should be easier/faster/better in C. (I understand that a Java developer who is using C not very often will disagree, but just because of personal perferences - which do not matter for rxtx users, because it can be considered an implementation detail). A suited JNI API and implementation IMHO is more powerful. The implementation can call select (or epoll or whatever) before each read/write to let it control timeouts, it could implement both intercharacter and total timeout, maybe also a min threshold or whatever and then have a Java implementation to downgrade this to the InputStream / OutputStream (specialized versions, of course, because at least some SerialInputStream.setTimeout() is needed). In future, I think it would be great if the now internal API to the powerful but `lower-level' JNI functionalities could be defined fixed, documented and `exported' to allow specific implementations (I'm not sure, but I assume that for example some PPP/TCP/IP stack could be better implemented on the JNI interface than on the InputStream-style interface, which, as already told, isn't sufficient anyway). For a version 3.0, why not adding new APIs if it is for good reason? The InputStream stuff isn't useable on it's own, applications have to know that in case of serial I/O setTimeout and whatever has to be called, so where is the problem in offering an appropriate interface (similar as the one used) instead of forcing applications to use the InputStream lookalike that behaves (slightly) differently? If an application relies on control signals, for instance, InputStream won't work anyway. And for those who do not have such requirements (may be most of the users) there of course should the InputStream still be present in a version 3.0. > And you could convert the C that calls read() > etc. to Java in a snap that way (the Java code will be almost exactly > the same with these wrappers!) > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then > call win32 function wrappers (Windows.CreateFile(), > Windows.ReadFile(), ...). But then the `portable' Java code has to know all those platform-specifics - beside potential performance issues due to heaps of calls. > 2) Have separate java implementations for a POSIX serial port and a > Windows serial port, both in Java, sounds a bit funny (`having a portable platform-dependent implementation for each platform in the portable platform-indepenent language') :-) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Aug 17 09:17:09 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 17 Aug 2010 08:17:09 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: My use of RXTX is to distribute it with another Java program (JMRI) RXTX is intensely useful _because_ it works on lots and lots of platforms. When that breaks down, as it has occasionally, and RXTX doesn't work on some specific platform, that's a problem. The last three times this happened, I tried to recompile RXTX to fix what appeared to be relatively simple problems with library versions. This was _not_ a success. I certainly understand that RXTX is a volunteer effort, and that the nitty-gritty of cross-platform compilation is not something that people generally do because they love it. But despite a lot of help from some really strong people, I wasn't able to build a version of RXTX that worked on all existing platforms _plus_ the new compilation. We are therefore currently working with three different sets of RXTX libraries, and there's currently a bug open that will probably require a 4th one. The problem is in compiling the C code. Compiling C code for N platforms is inherently difficult to do when you don't have all N platform's build environments available, and a real pain even when you do. If JNA can live up to it's promise of moving that C code over to Java code, then I think it's a major win. At least I'll be able to compile and distribute it! And if it's easier for me to do, I have to believe it'll be easier for the RXTX team to do it, issue new versions, etc. Bob From Kustaa.Nyholm at planmeca.com Tue Aug 17 10:14:38 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 19:14:38 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com>, Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADC@SRVFIHKIEXB01.pmgroup.local> >My use of RXTX is to distribute it with another Java program (JMRI) >RXTX is intensely useful _because_ it works on lots and lots of >platforms. When that breaks down, as it has occasionally, and RXTX > doesn't work on some specific platform, that's a problem. >The last three times this happened, I tried to recompile RXTX to fix >what appeared to be relatively simple problems with library versions. >This was _not_ a success. Hear hear! > The problem is in compiling the C code. Compiling C code for N >platforms is inherently difficult to do when you don't have all N > platform's build environments available, and a real pain even when you > do. Indeed! >If JNA can live up to it's promise of moving that C code over to Java >code, then I think it's a major win. At least I'll be able to compile >and distribute it! And if it's easier for me to do, I have to believe >it'll be easier for the RXTX team to do it, issue new versions, etc. Well put. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 10:35:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 19:35:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com>, <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> >In short, I think I like the JNI approach as done by rxtx. It >uses native code to handle the native platform specifics. That by itself has no value, as far as I can see. > It can use defines and whatever is needed to make it work even on un*x > systems which may have problems in termios or other > implementations. Platform specific defines are about the only thing one gains from using using 'native' code. But then again, the preferred distribution for any application, from the end user point of view, are compiled executables, so having platform dependencies handled by compile time decisions is bad. > As far as I know, this is common and > implementing serial I/O portable and correctly even today still > is a major challenge Agree. > - best done in C (or C++). Why? >Personally, I think Javas InputStream/OutputStream approach is >not suited for communications. A core problem is the missing > timeout support (boolean avialable(long timeout)) and that > bidirectional I/O might be tricky (to do without multithreading > and without polling), because there is not > `available_or_ready_to_write'. This is true as far as it goes. However we have timeout in rxtx and javacomm and many of us live with it. In any case the spec for rxtx/javacomm is what it is (ie it uses Streams) so we have to live with that in this context. And this of course has nothing to do with JNA/JNI. Surely we could create a new API that would fix these and other semantic issues with javacomm, and why not. However a lot of people use what we have today and would not like to change their code so any new API would be best created as separate API. >But why should it be easier/faster/better to implement low level >communications in Java than in C? Because you don't need to handle/understand two different language runtimes and don't have to have a C tool chain, which as many have testified here is often a major headache. >Looping around read/write >controlled by select or termios IMHO should be >easier/faster/better in C. (I understand that a Java developer >who is using C not very often will disagree, but just because of >personal perferences - which do not matter for rxtx users, >because it can be considered an implementation detail). On theoretical level it is an implementation level but in practice a lot of user are forced to compile the code and need to get into terms with the hell of getting C code to compile and link. > A suited JNI API and implementation IMHO is more powerful. The > implementation can call select (or epoll or whatever) before each > read/write to let it control timeouts, it could implement both > intercharacter and total timeout, maybe also a min threshold or > whatever and then have a Java implementation to downgrade this to > the InputStream / OutputStream (specialized versions, of course, > because at least some SerialInputStream.setTimeout() is needed). What ever you can do with JNI you can do more easily with JNA. I fail to see what are the advantages of implementing things on C. Performance is the only thing that comes to mind but that is an issue that needs to be considered in actual context with calculations and measurements, not with assumption that doing things on C is faster and therefore better. >In future, I think it would be great if the now internal API to > the powerful but `lower-level' JNI functionalities could be > defined fixed, documented and `exported' to allow specific > implementations (I'm not sure, but I assume that for example some > PPP/TCP/IP stack could be better implemented on the JNI interface > than on the InputStream-style interface, which, as already told, > isn't sufficient anyway). If such a cross platform C library existed it would be great and we would not need rxtx at all (except of course the existing code base) and could call directly that library using JNI or JNA. >For a version 3.0, why not adding new APIs if it is for good > reason? Why not create a new project for that? Let's keep rxtx what it is ie a replacement for javacomm. >But then the `portable' Java code has to know all those >platform-specifics - What is the objection to that? Either the C or Java side needs to do/know this and as demonstrated (IMO) doing it on the Java side has a lot of advantages. >beside potential performance issues due to heaps of calls. This is so loaded with assumptions that I won't bother. >> 2) Have separate java implementations for a POSIX serial port and a >> Windows serial port, both in Java, >sounds a bit funny (`having a portable platform-dependent >implementation for each platform in the portable >platform-indepenent language') :-) Yeah, I see the irony but to me it actually makes a lot of sense. br Kusti From adrian.crum at yahoo.com Tue Aug 17 12:16:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 17 Aug 2010 11:16:00 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> Message-ID: <102598.14191.qm@web63101.mail.re1.yahoo.com> --- On Tue, 8/17/10, Kustaa Nyholm wrote: > What ever you can do with JNI you can do more easily with > JNA. > I fail to see what are the advantages of implementing > things on C. Let's make one thing perfectly clear - using JNA instead of JNI will NOT make things easier. You're simply moving code up the stack from C to Java - but it will still be the same code. Instead of trying to convince everyone how easy JNA is based on a simple printf example in a Wiki - why don't you prove it? Implement RXTX using JNA and make us all believers. Until then, you're just making things up. -Adrian From bschlining at gmail.com Tue Aug 17 12:40:20 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 17 Aug 2010 11:40:20 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: > > > > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi > > Tried to find some documentation or tutorial but couldn't ...so what is the > difference / advantage? > > Does it work on all the platforms where JNA works? > I think JRuby is now using JFFI for native code interaction; so yes it should be very cross-platform. The author of JFFI is a contributor to both JRuby and JNA (See http://www.mail-archive.com/dev at jruby.codehaus.org/msg03607.html) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucio at sulweb.org Tue Aug 17 15:14:43 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 23:14:43 +0200 Subject: [Rxtx] JNA alternative (was: rxtx moving from JNI to JNA (was Re: About JRE crashes)) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: <201008172314.43315.lucio@sulweb.org> August 17 2010 16:55:36, Steffen DETTMER wrote: > just because of > personal perferences - which do not matter for rxtx users, > because it can be considered an implementation detail). I agree that users don't really care about how things work, but only until they are forced to understand them in order to have a patch applied. Personally I like the JNA idea, but there is at least one other less intrusive solution to the problem, that is to stay with JNI and to provide unofficial, unsupported, nightly (or weekly/monthly) cvs snapshot builds that include all the somewhat tested patches so far. That way users can try one of the snapshot builds instead of building from source themselves. What's the meaning of "somewhat tested patches"? Well, maybe any patch downloadable from a "resolved" bug report (but bug 144 is still "NEW" while a patch does exist and seems to work, so we have to decide the exact rules that make patches go into the snapshot build). The resulting build will be unsupported after all, just the same way a compilation done by a casual user is unofficial and unsupported. When the user knows a particurlar patch solves his problems, he can (if he likes) grab cvs sources, apply only that one patch he needs, set up a build environment and compile sources himself: at least the user will know in advance he is not wasting hours of time to apply a possibly useless-for-him patch. Or he can live with the unofficial and unsupported snapshot if he finds it works for him. Let me know what you think about my proposal. Since in the current situation I'm forced to set up a build environment for linux only to test the patch attached to bug 144 on linux, I could provide unofficial and unsupported builds for linux platforms on a regular basis if someone helps me spot the patches and distinguish between the "somewhat tested" ones and the others. From Kustaa.Nyholm at planmeca.com Wed Aug 18 02:52:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 11:52:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: > Let's make one thing perfectly clear - using JNA instead of JNI will NOT make > things easier. Depends on what 'things' you are talking about and in what context and for who it does not make things easier. But it is difficult to see your point of view ie why would it not be easier if you don't have to deal with two tool chains and languages. > You're simply moving code up the stack from C to Java - but it > will still be the same code. Of course the code is the same, but the practicalities are hugely different. > Instead of trying to convince everyone how easy JNA is based on a simple > printf example in a Wiki - why don't you prove it? > Implement RXTX using JNA and make us all believers. I have no need to convince you or anyone else, I'm happy with rxtx the way it is at the moment. As long as I can get a pre-compiled binary that just works for the platforms that I need it for, it is all that I need. I was talking in the context of someone's suggestion that a re-write is contemplated and was merely suggesting that in that case it might make sense to to get rid of the C stuff and the associated practical problems. > Until then, you're just making things up. I don't think that was a gentlemanly remark worth of a reply. br Kusti From george.dma at gmail.com Wed Aug 18 03:31:44 2010 From: george.dma at gmail.com (George H) Date: Wed, 18 Aug 2010 12:31:44 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: On Wed, Aug 18, 2010 at 11:52 AM, Kustaa Nyholm wrote: > >> Instead of trying to convince everyone how easy JNA is based on a simple >> printf example in a Wiki - why don't you prove it? >> Implement RXTX using JNA and make us all believers. > > I have no need to convince you or anyone else, I'm happy with rxtx the > way it is at the moment. As long as I can get a pre-compiled binary that > just works for the platforms that I need it for, it is all that I need. > > I was talking in the context of someone's suggestion that a re-write is > contemplated and was merely suggesting that in that case it might make > sense to to get rid of the C stuff and the associated practical problems. > Yeah it seems that context got taken out of hand. Adrian Crum was talking about re-write here http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html There is still the part of performance issue mentioned by many. And this one got lost from the thread since the subject changed http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html If you are happy with how RXTX is then continue to be happy, provide input and let developers be open to experimentation. It seems you are pretty adamant about using JNA. It seems to be good for a lot of things but maybe not for RXTX. The only way i can see JNA being used productively in RXTX is to be the proxy pattern between the Java code and the Native rxtx code. From what I read on this list and from looking at the native source code, it is likely that a performance hit will be a big issue if the code is moved up the stack to java. Should some people disagree then they should do a performance test with a test lib where they shifted some of the code up the stack. >> Until then, you're just making things up. > > I don't think that was a gentlemanly remark worth of a reply. > Don't take it personally, we are all computer people, we trust evidence based on experiments and benchmarks more than people's claims. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Wed Aug 18 04:07:10 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 18 Aug 2010 20:07:10 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <102598.14191.qm@web63101.mail.re1.yahoo.com> References: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: <14743-1282126034-652758@sneakemail.com> The main difference is that your wrapper for, say, select() is generated by JNA and doesnt have to be hand coded in JNI with C/C++. In my mind thats an advantage and in deed does make things easier. But as said, there might be other reasons why not to use it, maybe the wrappers are not as nice? What does JNA do with pointers to structs passed into functions? Do you have to deal with raw memory in Java? (you can avoid both in hand written JNI wrappers). How does it deal with os functions like ReadFile() when doing async I/O where the OS holds on to a buffer after the function returns? I have written quite a fair bit of Jni code lately, and these are the things that can make your life difficult if not handled correctly. But youre right, eventually someone has to go out and try it for rxtx ;-) Uwe On 18/08/2010 4:25 AM, "Adrian Crum adrian.crum-at-yahoo.com |rxtx.orgmailing list/Example Allow|" < drvwbrbtut at sneakemail.com> wrote: --- On Tue, 8/17/10, Kustaa Nyholm wrote: > What ever you can do with J... Let's make one thing perfectly clear - using JNA instead of JNI will NOT make things easier. You're simply moving code up the stack from C to Java - but it will still be the same code. Instead of trying to convince everyone how easy JNA is based on a simple printf example in a Wiki - why don't you prove it? Implement RXTX using JNA and make us all believers. Until then, you're just making things up. -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://ma... -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Wed Aug 18 04:07:10 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 18 Aug 2010 20:07:10 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <14740-1282126020-515157@sneakemail.com> Have a look at jpathwatch, it is exactly implemented like that. The only thing thats different to what's dicussed here is that it's low level OS wrappers are implemented in JNI instead of JNA (with typically 10 lines of C++ code each) But whatever your approach for the wrapper (and I see reasons for and against JNA), it shows how simple it can be to implement platform specific code in java when you only do in native code what you absolutely have to. Cheers, Uwe On 18/08/2010 4:49 AM, "Brian Schlining bschlining-at-gmail.com |rxtx.orgmailing list/Example Allow|" < 5j55m8uw1t at sneakemail.com> wrote: > > > > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi > > Tried to find so... I think JRuby is now using JFFI for native code interaction; so yes it should be very cross-platform. The author of JFFI is a contributor to both JRuby and JNA (See http://www.mail-archive.com/dev at jruby.codehaus.org/msg03607.html) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Wed Aug 18 04:14:15 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 18 Aug 2010 12:14:15 +0200 Subject: [Rxtx] what's the status of these new patches Message-ID: <4C6BB277.1050400@lfarkas.org> hi, i'm just check the cvs server and there is nothing changed on it in the last few months. is the patches recently appear on this list are dropped or use som kind of other version control system or just not yet applied? thanks. regards. -- Levente "Si vis pacem para bellum!" From adrian.crum at yahoo.com Wed Aug 18 07:15:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 06:15:43 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <3522.82736.qm@web63106.mail.re1.yahoo.com> --- On Wed, 8/18/10, George H wrote: > Kustaa Nyholm > > wrote: > > > >> Instead of trying to convince everyone how easy > JNA is based on a simple > >> printf example in a Wiki - why don't you prove > it? > >> Implement RXTX using JNA and make us all > believers. > > > > I have no need to convince you or anyone else, I'm > happy with rxtx the > > way it is at the moment. As long as I can get a > pre-compiled binary that > > just works for the platforms that I need it for, it is > all that I need. > > > > I was talking in the context of someone's suggestion > that a re-write is > > contemplated and was merely suggesting that in that > case it might make > > sense to to get rid of the C stuff and the associated > practical problems. > > > > Yeah it seems that context got taken out of hand. > Adrian Crum was talking about re-write here > http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html > > There is still the part of performance issue mentioned by > many. And > this one got lost from the thread since the subject > changed > http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html Thank you for bringing this back to the original subject. I tried to fix the JRE crash issue, but I gave up because of two main reasons: the C code is unnecessarily complicated, and error return codes are being ignored. The basic problem I ran into is: Java code calls native method A, native method A calls native method B, and native method B calls native method C. Method C encounters an error and returns an error code to method B. Method B ignores the returned error code and returns success to method A. Java code doesn't know there was an error and continues operating like nothing is wrong. I started fixing the existing code so error codes would be propagated back to Java, but then what do I do with the error code when it's time to return to Java? The original javax.comm specification doesn't allow for errors returned from native code. I also ran into places where threads are being started in native code - which is a bad idea because you could lose control over the thread after you return to Java. Then I found thread synchronization problems in the code... So, I decided to rewrite the library. So far I have the Java code rewritten, and I am currently working on the Windows native code. Once I have it all working, I will make a formal proposal for a new version, post the code, and we can take it from there. I believe once the code is simplified, many of the quirky bugs will go away, deploying native code will be easier, and any discussions about switching to JNA will be moot. -Adrian From george.dma at gmail.com Wed Aug 18 07:38:30 2010 From: george.dma at gmail.com (George H) Date: Wed, 18 Aug 2010 16:38:30 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <3522.82736.qm@web63106.mail.re1.yahoo.com> References: <3522.82736.qm@web63106.mail.re1.yahoo.com> Message-ID: On Wed, Aug 18, 2010 at 4:15 PM, Adrian Crum wrote: > --- On Wed, 8/18/10, George H wrote: >> Kustaa Nyholm >> >> wrote: >> > >> >> Instead of trying to convince everyone how easy >> JNA is based on a simple >> >> printf example in a Wiki - why don't you prove >> it? >> >> Implement RXTX using JNA and make us all >> believers. >> > >> > I have no need to convince you or anyone else, I'm >> happy with rxtx the >> > way it is at the moment. As long as I can get a >> pre-compiled binary that >> > just works for the platforms that I need it for, it is >> all that I need. >> > >> > I was talking in the context of someone's suggestion >> that a re-write is >> > contemplated and was merely suggesting that in that >> case it might make >> > sense to to get rid of the C stuff and the associated >> practical problems. >> > >> >> Yeah it seems that context got taken out of hand. >> Adrian Crum was talking about re-write here >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html >> >> There is still the part of performance issue mentioned by >> many. And >> this one got lost from the thread since the subject >> changed >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html > > Thank you for bringing this back to the original subject. > > I tried to fix the JRE crash issue, but I gave up because of two main reasons: the C code is unnecessarily complicated, and error return codes are being ignored. > > The basic problem I ran into is: Java code calls native method A, native method A calls native method B, and native method B calls native method C. Method C encounters an error and returns an error code to method B. Method B ignores the returned error code and returns success to method A. Java code doesn't know there was an error and continues operating like nothing is wrong. > > I started fixing the existing code so error codes would be propagated back to Java, but then what do I do with the error code when it's time to return to Java? The original javax.comm specification doesn't allow for errors returned from native code. > > I also ran into places where threads are being started in native code - which is a bad idea because you could lose control over the thread after you return to Java. Then I found thread synchronization problems in the code... > > So, I decided to rewrite the library. So far I have the Java code rewritten, and I am currently working on the Windows native code. Once I have it all working, I will make a formal proposal for a new version, post the code, and we can take it from there. > > I believe once the code is simplified, many of the quirky bugs will go away, deploying native code will be easier, and any discussions about switching to JNA will be moot. > > -Adrian > I'm glad that you are taking the initiative to fix these problems and we're all happy because it will benefit us, or at least not yet for me since I am a Linux user :) I do take your word for it about re-writing and it seems you have jump-started the process and the other devs are getting their interest back. btw, I don't know about the javax.comm specs but I would certainly want errors to be returned from native code if it was me. Imagine I call a function from a native library and somewhere inside something bad happens that causes my action to yield an undesirable result. I would want to know that. That is to say that if the result is undesirable then I would want to know, if it is some lower error that maybe can be ignored or occurs anyways for some reason but does not affect the result of what I want, perhaps I wouldn't want that error to be propagated back up. It would cause the "I get an error but it worked" response. Propagating errors... like throwing an exception back up to Java or returning a value (ie, -1 or null or false) indicating an error ? This would need a consensus of the you and the main devs. On a side note, I am happy to see activity in this project :) -- George H george.dma at gmail.com From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From msemtd at googlemail.com Thu Aug 12 04:59:43 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 11:59:43 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Message-ID: On 12 August 2010 10:33, M.Dec-GM wrote: > When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. > Because of this observation I have thought what may be faster as a normal message events queue. > Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! > Basing on this idea I have decide to NOT use serial events. > Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. > Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. > This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Hi Mariusz, That's a very effective and creative approach. You could consider a technique from the Java concurrency API, such as a LinkedBlockingDeque to share messages with the main application. That is my usual approach -- I will be posting a working example on the wiki when I have time. If you put your code on the wiki also then the users will have more examples to work from. Regards, Michael. From psuhas at gmail.com Thu Aug 12 14:57:52 2010 From: psuhas at gmail.com (Suhas Pharkute) Date: Thu, 12 Aug 2010 14:57:52 -0600 Subject: [Rxtx] Error in Java Message-ID: Hi, I am getting an error when I load an applet in xulrunner app (mozilla) java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: no suitable image found. Did find: /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper When I did my research it shows me that I need to use -d32 option while launching JVM. I am not sure how to do that? Can some one please help. Thank you, Suhas Pharkute (805) 229-1450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 00:37:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:37:39 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >>> I would also suggest that by using JNA we could get rid of the C code >>> altogether, making (no pun intended) building the code a trivial effort. > >> Anything that would make it easier to deploy and have less reliance on native >> code would be greatly appreciated from a end-user?perspective.? > > With JNA all the interface code is pure Java and JNA itself is a single .jar > file, so deployment is very simple. No platform specific native libraries, > DLLs etc etc. All you need is the jna.jar file in your classpath and > that is it. Or package the jna.jar with your Java application code and > you have a single cross platform executable solution. > > For an example on how easy it is to call standard C library printf from Java > in Mac OS X / Linux / Windows see: > > http://en.wikipedia.org/wiki/Java_Native_Access > > For details see the project home at: > > https://jna.dev.java.net/ > > >From the perspective of rxtx this is another possible direction. We don't need to decide if it is _the_ direction. Don't try to load the wagon with developers, show its the way to go. If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. The solution and problems presented by JNA are an interesting area I've been pondering. This falls more along the lines of catering to some platform specific APIs but using as little of them as possible. Catering to platform specific APIs is a net loss in my opinion but maybe it works. It moves the platform independance responsibility to rxtx in the end. I don't see that we have the resources to do this more than once. The original idea for rxtx was to target POSIX not to become POSIX. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Aug 16 00:47:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:47:39 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > >> The attached patch is cumulative - it includes the previous patches. >> >> A number of changes to make RXTXCommDriver and CommPortIdentifier >> thread-safe: >> >> 1. Converted CommPortIdentifier linked list to a HashMap and moved it to >> RXTXCommDriver, put RXTXCommDriver in control of the Map and have >> CommPortIdentifier delegate method calls to RXTXCommDriver. >> >> There was a flaw in the design. One thread could be traversing the linked >> list while another thread is modifying it - causing unpredictable results >> or NPEs. >> >> 2. Synchronized access to the listener Vector in CommPortIdentifier. >> >> 3. Fixed the open method in CommPortIdentifier. Even though the method >> included synchronized blocks, it was not thread-safe - another thread could >> change the object's state in the gaps between the synchronized blocks. >> >> This will be my last patch for now. If these changes make it into the >> project, then I will submit more. >> > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the changes this week. > I'll let you know if I find anything. > I'm just following up to let you know this isnt sitting on a dusty shelf. The patches look fine. I have a meeting Tuesday about testing them. There is a possibility to streamline the process on my end so I'm taking the time to do it. Basically, I use rxtx at work as well and have access to a build and test system that covers the main platforms and has tests used since ~2000 for rxtx. I suspect I'll be able to push this through a set of nontrivial tests Wednesday. Maybe we can get some code coverage numbers as a bonus. I'm also looking at making the tests available outside of that harness. Its something I'm in favor of but takes more than a Tuesday meeting :) -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 16 08:32:25 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 07:32:25 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <54491.35492.qm@web63107.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > > > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > >> The attached patch is cumulative - it includes the > previous patches. > >> > >> A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > >> > >> 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > >> > >> There was a flaw in the design. One thread could > be traversing the linked list while another thread is > modifying it - causing unpredictable results or NPEs. > >> > >> 2. Synchronized access to the listener Vector in > CommPortIdentifier. > >> > >> 3. Fixed the open method in CommPortIdentifier. > Even though the method included synchronized blocks, it was > not thread-safe - another thread could change the object's > state in the gaps between the synchronized blocks. > >> > >> This will be my last patch for now. If these > changes make it into the project, then I will submit more. > >> > > > > Thanks Adrian, > > > > I'll be reviewing these and running a test suite on > the changes this week. I'll let you know if I find > anything. > > > > I'm just following up to let you know this isnt sitting on > a dusty shelf. > > The patches look fine.? I have a meeting Tuesday about > testing them. There is a possibility to streamline the > process on my end so I'm taking the time to do it.? > Basically, I use rxtx at work as well and have access to a > build and test system that covers the main platforms and has > tests used since ~2000 for rxtx. > > I suspect I'll be able to push this through a set of > nontrivial tests Wednesday.? Maybe we can get some code > coverage numbers as a bonus. > > I'm also looking at making the tests available outside of > that harness. Its something I'm in favor of but takes more > than a Tuesday meeting :) You must have missed my previous reply. Don't worry about that patch - I have abandoned work on 2.x in favor of a rewrite. I will have a formal V3 proposal ready in about a week. The first patch should get committed though - the one that fixes the properties file issues. In fact, that should be backported to previous versions. -Adrian From adrian.crum at yahoo.com Mon Aug 16 09:08:55 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 08:08:55 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <370266.35744.qm@web63104.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user?perspective.? > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction.? We don't > need to decide if it is _the_ direction.? Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory.? If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering.? This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works.? It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian From mariusz.dec at gmail.com Mon Aug 16 11:26:43 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Mon, 16 Aug 2010 19:26:43 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <0C4CFD3F08FE4FCCBD2F297DB56928EB@mdam2> Hi all, A bit Off Topic.... And we are going "back to the future" :))). Java was developed to be platform independent. Very nice idea but.... who knows Operating Systems rules, know what about I am thinking. Finally - everybody is looking how to do Java platform dependend because of ... performance. Surprise or not??? Ok - this example from Wiki gives multiplatform code on the higher level than conditionals in C code and THIS IS a very big step ahead comparing to early 90'ths... I am not Java enemy, but Java's overhead (in fact OS over OS) should be very carefully analysed before use Java on the small/relative slow platforms. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Monday, August 16, 2010 5:08 PM Subject: Re: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user perspective. > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction. We don't > need to decide if it is _the_ direction. Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory. If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering. This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works. It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon Aug 16 11:27:32 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 16 Aug 2010 10:27:32 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > > > > > Catering to platform specific APIs is a net loss in my > > opinion but maybe > > it works. It moves the platform independance > > responsibility to rxtx in > > the end. I don't see that we have the resources to do this > > more than > > once. > > I looked at JNA briefly, and I don't like going in that direction. > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 16:05:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 16:05:21 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Mon, 16 Aug 2010, Adrian Crum wrote: > --- On Sun, 8/15/10, Trent Jarvi wrote: >> On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >> >>>>> I would also suggest that by using JNA we >> could get rid of the C code >>>>> altogether, making (no pun intended) building >> the code a trivial effort. >>> >>>> Anything that would make it easier to deploy and >> have less reliance on native >>>> code would be greatly appreciated from a >> end-user?perspective.? >>> >>> With JNA all the interface code is pure Java and JNA >> itself is a single .jar >>> file, so deployment is very simple. No platform >> specific native libraries, >>> DLLs etc etc. All you need is the jna.jar file in your >> classpath and >>> that is it. Or package the jna.jar with your Java >> application code and >>> you have a single cross platform executable solution. >>> >>> For an example on how easy it is to call standard C >> library printf from Java >>> in Mac OS X / Linux / Windows see: >>> >>> http://en.wikipedia.org/wiki/Java_Native_Access >>> >>> For details see the project home at: >>> >>> https://jna.dev.java.net/ >>> >>> >> >> From the perspective of rxtx this is another possible >> direction.? We don't >> need to decide if it is _the_ direction.? Don't try to >> load the wagon with >> developers, show its the way to go. >> >> If you like, I can give cvs access and people can go nuts >> in a JNA >> directory.? If it becomes obvious that we should do >> that, great. >> >> The solution and problems presented by JNA are an >> interesting area I've >> been pondering.? This falls more along the lines of >> catering to some >> platform specific APIs but using as little of them as >> possible. >> >> Catering to platform specific APIs is a net loss in my >> opinion but maybe >> it works.? It moves the platform independance >> responsibility to rxtx in >> the end. I don't see that we have the resources to do this >> more than >> once. > > I looked at JNA briefly, and I don't like going in that direction. > >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > The termios (basically all the serial specific stuff) calls are POSIX calls. Right now, the API exists and is supported on windows but not all versions. Microsoft has started including the POSIX layer in their servers, if they do it for all their systems, the funky code in rxtx that provices ioctl/termios/... for windows could go away with a few minor adjustments. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:20:09 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:20:09 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi? Tried to find some documentation or tutorial but couldn't ...so what is the difference / advantage? Does it work on all the platforms where JNA works? br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:30:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:30:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > I looked at JNA briefly, and I don't like going in that direction. > Ok, but it would be helpful if you elaborated a bit... the point about JNA is ease of deployment and development. In my experience the simple task of compiling C as you need to do with JNI can be a major headache especially for user and in open source projects users are often told to 'grab the latest CVS and compile' which more often than not does not work out of the box. >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > I too did not get what this means...how accessing the serial port from Java with a few JNA calls would make rxtx become POSIX. >From the users points of view expectation for rxtx is that it is the replacement for Sun's abandoned javacomm. And the expectation for javacomm is that we can access the serial port from Java in a platform independent manner. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:43:48 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:43:48 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: don't like going in that direction. >> >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their > servers, if they do it for all their systems, the funky code in rxtx > that provices ioctl/termios/... for windows could go away with a few > minor adjustments. > > -- > Trent Jarvi > tjarvi at qbang.org I may have lost the thread a bit but ... maybe that is because I have not looked into the rxtx code. >From above I gather that rxtx is coded so that it works on POSIX and on Windows there is some C code that makes Windows look more or less like POSIX, is this correct? On the face of it, that looks very reasonable. What I was suggesting was to just do the low level access to the OS using JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that can easily be coded in Java. The ease of development, maintenance and deployment is so much better with JNA than with JNI. All the developer has to do is to include the jna.jar in the classpath and create a few classes/interfaces in Java. No C compiler and the associated pain in sight. The same goes for the users of rxtx (if it takes the JNA route) and even for the users of those applications using rxtx. br Kusti From adrian.crum at yahoo.com Tue Aug 17 00:56:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 23:56:47 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <333325.87714.qm@web63106.mail.re1.yahoo.com> --- On Mon, 8/16/10, Kustaa Nyholm wrote: > > I looked at JNA briefly, and I don't like going in > that direction. > > > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. I don't see where it makes development or deployment any easier. > In my experience the simple task of compiling C as you need > to do with > JNI can be a major headache especially for user and in open > source > projects users are often told to 'grab the latest CVS and > compile' > which more often than not does not work out of the box. Are you experiencing that headache with this project in particular? I haven't used C in years, and I was able to download the RXTX repo, set up my dev environment and get it to compile within a few hours. > >> The original idea for rxtx was to target POSIX not > to > >> become POSIX. > > > > Could you elaborate on that more? How does POSIX > relate to RXTX? > > > > I too did not get what this means...how accessing the > serial port > from Java with a few JNA calls would make rxtx become > POSIX. What Trent is saying is that RXTX interacts with port hardware using the POSIX API: Java -> JNI -> RXTX native code -> POSIX API -> port hardware -Adrian From george.dma at gmail.com Tue Aug 17 00:59:22 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 09:59:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Tue, Aug 17, 2010 at 9:30 AM, Kustaa Nyholm wrote: > >> >> I looked at JNA briefly, and I don't like going in that direction. >> > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. > In my opinion JNA is just a proxy pattern for gluing the native libs to your java code. Lets say you used JNA with rxtx, you would still needed to code, compile and debug the windows DLL and the linux SO files anyways. In fact this may make development a bit harder. Already in rxtx they have the java side of the code and the C (windows and linux) side of it. And in the middle are the JNI classes that bind things together. When you deploy the jar files, you add them to your class path. JNA may make that part a tad simpler but not by a mile. Using JNA still means you have to work with the native code and they might as well just keep things the way they are. Perhaps organize it more or something. See these references http://today.java.net/article/2009/11/11/simplify-native-code-access-jna https://jna.dev.java.net/ >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > I too did not get what this means...how accessing the serial port > from Java with a few JNA calls would make rxtx become POSIX. > I believe that sounded a bit odd too. rxtx is "targeting" POSIX and Win32 and others anyways. They write the native libs that access the underlying OS to communicate with the serial/parallel ports. So either way with or without JNA you still have to compile,code,debug the native stuff. Providing the native source files is better as you can compile and run it. If you had JNA (I assume) you'd need to compile, package the native lives into some JNA jar package then test it. Trent said > If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. Why not, if it proves to work then great. If not then it doesn't harm anything. -- George H george.dma at gmail.com From mariusz.dec at gmail.com Tue Aug 17 01:25:00 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 09:25:00 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> ----- Original Message ----- From: "George H" To: Sent: Tuesday, August 17, 2010 8:59 AM > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. I agree - 300 percent :). When I am using RXTX in W/M/L environment with JNI, I suppose that peoples like Trent knows many, many more than me about NATIVE W/M/L/.... calls. I don't want to learn about all-platforms-native-calls because rest of the applications need a lot of time as well!!! This is why Java was developed...., I think... WE (programmers) have currently so many things to remember that ready for use JNI like RXTX is very usefull. The important thing is good planning if computing power of the machine with our aplication will be enough for OS over OS (Java over W/M/L/.....). Regards Mariusz From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:34:51 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:34:51 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <333325.87714.qm@web63106.mail.re1.yahoo.com> Message-ID: > > I don't see where it makes development or deployment any easier. > > Are you experiencing that headache with this project in particular? Yes, a few years ago I was able to pull the CVS version and get it to compile on my Mac with just minor adjustments. A year and two Mac's later last year I could not not. I now rely on a precompiled binary and hope it won't break. And no, I have not tried the latest CVS with my latest Mac as I have other things to do than trying to figure out why this or that configure/make/install fails. > I haven't > used C in years, and I was able to download the RXTX repo, set up my dev > environment and get it to compile within a few hours. A few hours?! If it was based on JNA it should be minutes. And that few hours was just for your platform (what ever it is), how about doing this for all the platforms? N times a few hours. > > What Trent is saying is that RXTX interacts with port hardware using the POSIX > API: > > Java -> JNI -> RXTX native code -> POSIX API -> port hardware > > -Adrian > Thanks, got it now. br Kusti From lucio at sulweb.org Tue Aug 17 01:39:25 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 09:39:25 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <201008170939.25390.lucio@sulweb.org> August 17 2010 08:59:22, George H wrote: > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. I believe it is more effectively used to glue your java code to *others* native libs (e.g. host OS native libs). > Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. The point is, with JNA you don't need to write native code in C anymore, you write it in java and call OS native libs directly from java when needed with runtime lookup of function pointers. This way compilation is easier for users of the rxtx library. I agree debugging and developing rxtx can become a little harder. That said, I've no practical JNA knowledge, so it's more than likely that I miss some important JNA details. August 17 2010 08:43:48, Kustaa Nyholm wrote: > What I was suggesting was to just do the low level access to the OS using > JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that > can easily be coded in Java. Exactly what I mean. August 17 2010 08:56:47, Adrian Crum wrote: > Are you experiencing that headache with this project in particular? I > haven't used C in years, and I was able to download the RXTX repo, set up > my dev environment and get it to compile within a few hours. *A FEW HOURS*? Such a time to setup a build environment is way too much for most rxtx users (non-rxtx-developers), especially since it is a very commonly suggested way to grab the best rxtx code. A library user expects to be able to download it and use it in a few seconds, not hours. For example I need just now to grab the sources only for the crashes problem, and "a few hours", assuming all goes well, seem a bit too much since I don't plan to become a rxtx developer. I think JNA could make this situation better. My 2 cents, Lucio. From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:44:43 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:44:43 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. No, not correct. With JNA you don't need a C compiler and you don't need to compile any DLL/SOs. Did you check the example in the wikipedia about calling printf? Absolutely no C-code involved. If and when your favorite OS provides an API you can call from C and link to your application, using JNA you just write a Java interface that conforms to the calling convention and point it to the system library and that is it. > > Already in rxtx they have the java side of the code and the C (windows > and linux) side of it. And in the middle are the JNI classes that bind > things together. I was suggesting, in the context of rewriting things, getting rid of the C side of things. > When you deploy the jar files, you add them to your > class path. JNA may make that part a tad simpler but not by a mile. If you have precompiled (rxtx) libraries available, there is not a big difference, but if you are *developing* a cross platform library there is world of difference in setting up the tool chains for all the platforms and keeping them up-to-date. And like I said, user of open source libraries too often have to compile them. > > Using JNA still means you have to work with the native code and they > might as well just keep things the way they are. Perhaps organize it > more or something. > Like I said, my comments were in the context of rewriting things. If the current code base is just tweaked or improved, naturally there is no point in upsetting things by introducing anything to replace JNI, but if the code is rewritten, then I think it would make sense to seriously consider getting rid of the C-side of things and use JNA. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:54:25 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:54:25 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > I agree - 300 percent :). Agree with what? Agree with the wrong conclusion that you still need DLL and/or SO files anyway? Agree with the misguided conclusion that when you don't need to maintain a C compiler tool chain and don't have to debug both C and Java the development is a bit harder? > When I am using RXTX in W/M/L environment with JNI, I suppose that peoples > like Trent knows many, many more than me about NATIVE W/M/L/.... calls. > I don't want to learn about all-platforms-native-calls because rest of the > applications need a lot of time as well!!! The whole point of RXTX is of course that you don't need to know these things. So JNA versus JNI should be mostly irrelevant to you. That is why I don't understand why you care what RXTX does internally and don't understand why you agree 300% with an opinion that dismisses JNA in favor of JNI based on disinformation and out of context. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 02:01:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 11:01:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <201008170939.25390.lucio@sulweb.org> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. > > I believe it is more effectively used to glue your java code to *others* > native > libs (e.g. host OS native libs). Exactly! > >> Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > The point is, with JNA you don't need to write native code in C anymore, you > write it in java and call OS native libs directly from java when needed with > runtime lookup of function pointers. This way compilation is easier for users > of the rxtx library. I agree debugging and developing rxtx can become a little > harder. That said, I've no practical JNA knowledge, so it's more than likely > that I miss some important JNA details. I have practical knowledge of both JNA and JNI on Linux/Windows/Mac setting using JNA things are so much easier. And when we are talking about calls to native system API, I think debugging is also easier because you don't realy want to step into system calls anyway so all you debugging is on the Java side. There is no C side to debug, hence no need to debug that and as a bonus, provided you pass sensible values to the system calls there is nothing that can crash as Java programs just throw exceptions which are easy to catch, handle and debug. > > August 17 2010 08:43:48, Kustaa Nyholm wrote: >> What I was suggesting was to just do the low level access to the OS using >> JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that >> can easily be coded in Java. > > Exactly what I mean. We are so much on the same page with this! > > August 17 2010 08:56:47, Adrian Crum wrote: >> Are you experiencing that headache with this project in particular? I >> haven't used C in years, and I was able to download the RXTX repo, set up >> my dev environment and get it to compile within a few hours. > > *A FEW HOURS*? Such a time to setup a build environment is way too much for > most rxtx users (non-rxtx-developers), especially since it is a very commonly > suggested way to grab the best rxtx code. A library user expects to be able to > download it and use it in a few seconds, not hours. For example I need just > now to grab the sources only for the crashes problem, and "a few hours", > assuming all goes well, seem a bit too much since I don't plan to become a > rxtx developer. > Could not agree with you more. > I think JNA could make this situation better. I'm sure it would. br Kusti From george.dma at gmail.com Tue Aug 17 02:20:13 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 11:20:13 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Tue, Aug 17, 2010 at 10:44 AM, Kustaa Nyholm wrote: > >> >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. > > No, not correct. With JNA you don't need a C compiler and you don't need > to compile any DLL/SOs. > > Did you check the example in the wikipedia about calling printf? > > Absolutely no C-code involved. > > If and when your favorite OS provides an API you can call from C and > link to your application, using JNA you just write a Java interface > that conforms to the calling convention and point it to the system > library and that is it. > I have seen the JNA project and I do agree that it creates the interface for you for calling native libraries. It works great if you are just looking to call a method from a native API. I've done this before using JNI and in most cases I've seen using JNA for me would be good. But the problem I see is when I look at the rxtx C source code. I see a lot more than that, there is a quite a bulk of work that is being done. I was seeing using JNA as the abstraction layer between the rxtx java code and the rxtx native code. To which if that was the case then JNA would be a bit useless. I guess I fell into that trap by not explaining too much. So for that I do apologize. However when you mention a complete re-write, this is where things get interesting. This is also where I agree with Trent on making a JNA directory and letting devs go wild and see if this works. I assume they'd have to use JNA to create the access to the native libs. Then just test it to see if everything works. Then I'd assume they'd have to scan the current native code and see what extra calculations and algorithms are being done and apply them in the java code. This part I guess would be time consuming, so it will take effort and time to migrate fully with JNA. I am not the lead of the project and I believe creating a JNA dir for research, dev and testing is a good idea. It helps current rxtx devs to carry on and new devs to re-write portions of the project to use JNA. Then it depends on the project lead as to how the project will evolve. Effectively I would like to hear more technical details from lead devs on this issue, perhaps they can write out the pros and cons on the development side and on the deployment side. This is why I am not really against but not really for JNA. I am for people testing it out, definitely. I am also for keeping what currently works. From mariusz.dec at gmail.com Tue Aug 17 02:31:04 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 10:31:04 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: Message-ID: <8129C8E0DD78429D8E8350B8E5474DC7@mdam2> ----- Original Message ----- From: "Kustaa Nyholm" >>> files anyways. In fact this may make development a bit harder. >> >> I agree - 300 percent :). > > Agree with what? Take it easy Kusti :). I was thinking that this is harder because of looking for native calls structure. For example - I know where and how to look for Windows data about it, but I don't know today where to look for it in Linux/Macintosh. I know google, but what for loosing time if I don't think I will be native-programmer in L/M/... > > > The whole point of RXTX is of course that you don't need to know these > things. So JNA versus JNI should be mostly irrelevant to you. > > That is why I don't understand why you care what RXTX does internally and > don't understand why you agree 300% with an opinion that dismisses JNA in > favor of JNI based on disinformation and out of context. > > br Kusti > Ok, in wide context general change of RXTX to JNA looks not bad, if SOMEBOEDY will do it and test it. But if RXTX (as is today) works ....? In our country peoples saying: - Better is the enemy of the good.... When I was writing this post, George H has wriiten about time needed for Java, if Java will do some things as RXTX-C part. So I do not need to rewrite nothing about this very important point :). Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From iqzw2r602 at sneakemail.com Tue Aug 17 02:55:24 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 18:55:24 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <4850-1282035324-678892@sneakemail.com> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their servers, > if they do it for all their systems, the funky code in rxtx that provices > ioctl/termios/... for windows could go away with a few minor adjustments. > That sounds like an appealing option for a rxtx 2.3; reducing complexity is always good for code that should live long. I wonder if that's the way to go for 3.0 though. From first hand experience, the slim direct OS wrapper approach (to have native Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much easier to debug and maintain, because you will not have to debug native code any more. And you could convert the C that calls read() etc. to Java in a snap that way (the Java code will be almost exactly the same with these wrappers!) The solution on Windows can be to either 1) convert your win32 termios wrappers to Java as well, and make Java-converted SerialImp.c code call them. The Java termios can then call win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). 2) Have separate java implementations for a POSIX serial port and a Windows serial port, both in Java, that access the OS via the mentioned slim wrappers. That's the approach that I used for jpathwatch, which has worked very well for me. Option 1) is probably the least work, option 2) the more sustainable and likely to perform better. You can actually do them both in order, because you can later migrate from 1) to 2). And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; they're stable and tested, and exist for Unix and Windows. All that needs to be done is to follow the pattern and add the OS functions you're missing, which I'm happy to assist with. Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Aug 17 03:15:34 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 12:15:34 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically all the serial specific stuff) calls are POSIX >> calls.. ?Right now, the API exists and is supported on windows but not all >> versions. ?Microsoft has started including the POSIX layer in their servers, >> if they do it for all their systems, the funky code in rxtx that provices >> ioctl/termios/... for windows could go away with a few minor adjustments. > > That sounds like an appealing option for a rxtx 2.3; reducing complexity is > always good for code that should live long. > > I wonder if that's the way to go for 3.0 though. From first hand experience, > the slim direct OS wrapper approach (to have native Unix.read(), > Unix.select(), Unix.open(), etc. java methods) is much easier to debug and > maintain, because you will not have to debug native code any more. And you > could convert the C that calls read() etc. to Java in a snap that way (the > Java code will be almost exactly the same with these wrappers!) > > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then call > win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). > 2) Have separate java implementations for a POSIX serial port and a Windows > serial port, both in Java, that access the OS via the mentioned slim > wrappers. That's the approach that I used for jpathwatch, which has worked > very well for me. > > Option 1) is probably the least work, option 2) the more sustainable and > likely to perform better. You can actually do them both in order, because > you can later migrate from 1) to 2). > > And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; > they're stable and tested, and exist for Unix and Windows. All that needs to > be done is to follow the pattern and add the OS functions you're missing, > which I'm happy to assist with. > > Cheers, > > Uwe > Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Tue Aug 17 06:14:42 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 22:14:42 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <16747-1282047283-672654@sneakemail.com> People post problems on the forums mainly, but youre right, its time to take the bug tracker online. So I just did. If you are look for past issues, look on the forums. Cheers, Uwe On 17/08/2010 7:23 PM, "George H george.dma-at-gmail.com |rxtx.org mailing list/Example Allow|" wrote: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically ... Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qban... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyon at docjava.com Tue Aug 17 06:28:29 2010 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Aug 2010 08:28:29 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: Hi All, Has anyone tried using JNA to gain access to web cams? Thanks! - Doug P.S. Quicktime for Java could do this, but Apple killed it. From Kustaa.Nyholm at planmeca.com Tue Aug 17 06:43:11 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 15:43:11 +0300 Subject: [Rxtx] JNA 4 web cams In-Reply-To: Message-ID: > Has anyone tried using JNA to gain access to web cams? Not a web cam but one of these: http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 took me about half an hour to convert the C-headers to a JNA interface and it worked no problem. br Kusti From Steffen.DETTMER at ingenico.com Tue Aug 17 08:09:44 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:09:44 +0200 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: <20100817140944.GA6209@elberon.bln.de.ingenico.com> (OT) * Trent Jarvi wrote on Thu, Aug 05, 2010 at 14:40 -0600: > Some people like it > http://www.metasystema.net/essays/reply-to.html > Some people don't > http://www.unicom.com/pw/reply-to-harmful.html I think both articles are at least around ten years old and I'm afraid the situation still is unchanged, unfortunately. MUAs with proper support of list reply functions, as far as I know, still are rather an exception than the rule - especially webmailers won't offer such a functionality and may not even support any kind of Plug-In that could help (as far as I know, which is very limited). I'm almost sure that even on the latest state-of-the-art hyper-pro-gold "iPhone" clone super device it won't work... Web 2.0, Flash and AJAX - but no mailinglists. Years ago I always was strongly against reply-to munging, because it overwrites the Reply-To: which should be in my authority and invites to accidently to reply to the list instead to the author, but nowadays I see so many problems with daily mails (such as that 95% of the people don't quote well but write 95% of the mails to me etc.), that this one doesn't count much any longer :) Sorry, could not resist, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Aug 17 08:18:42 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:18:42 +0200 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <20100817141842.GB6209@elberon.bln.de.ingenico.com> (OT) Hi Adrian, is it intended to mail to the list to all your postings? I pressed `reply' (not `reply to all'), but since reply-to field asks me to reply the list, so I do :) SCNR. * Adrian Crum wrote on Thu, Aug 05, 2010 at 14:31 -0700: > I'm the former. ;-) Replying to this list will be inconvenient > if I have to keep C&P the ml address in the To: field. I am sure you could find a mail client that makes it still inconvenient... (in other words, Yahoo etc. should be bothered to add this reasonable function) Usually the problem is not copying the ML address, because `reply to all' should set/keep it, but to remove the Authors address to avoid that he gets the mail twice. If you do not use `reply to all' but expect that you reply to all, I think then it is an operating error. SCNR. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From damorales at gmail.com Tue Aug 17 08:25:16 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 17 Aug 2010 10:25:16 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: very interesting ... right now i use v4l4j to use web cams in java apps, but only works on Linux (which is not a problem for me xD) Greetings !! 2010/8/17 Kustaa Nyholm > > > Has anyone tried using JNA to gain access to web cams? > > Not a web cam but one of these: > > > http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 > > took me about half an hour to convert the C-headers to a JNA interface and > it worked no problem. > > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Aug 17 08:55:36 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:55:36 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <20100817145536.GC6209@elberon.bln.de.ingenico.com> Hi, quite an interesting discussion. In short, I think I like the JNI approach as done by rxtx. It uses native code to handle the native platform specifics. It can use defines and whatever is needed to make it work even on un*x systems which may have problems in termios or other implementations. As far as I know, this is common and implementing serial I/O portable and correctly even today still is a major challenge - best done in C (or C++). * iqzw2r602 at sneakemail.com wrote on Tue, Aug 17, 2010 at 18:55 +1000: > > The termios (basically all the serial specific stuff) calls are > > POSIX calls.. Right now, the API exists and is supported on > > windows but not all versions. Microsoft has started including the > > POSIX layer in their servers, if they do it for all their systems, > > the funky code in rxtx that provices ioctl/termios/... for windows > > could go away with a few minor adjustments. So the Windows termios implementation is really usable? We have some C implementations and found it not fully be portable even across different linux versions - I guess, other un*x systems will be even more different... Personally, I think Javas InputStream/OutputStream approach is not suited for communications. A core problem is the missing timeout support (boolean avialable(long timeout)) and that bidirectional I/O might be tricky (to do without multithreading and without polling), because there is not `available_or_ready_to_write'. > That sounds like an appealing option for a rxtx 2.3; reducing > complexity is always good for code that should live long. > I wonder if that's the way to go for 3.0 though. From first hand > experience, the slim direct OS wrapper approach (to have native > Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much > easier to debug and maintain, because you will not have to debug > native code any more. But what for? I understand that when using JNA and handling the platform specifics in Java code, no native lib has to be deployed, which can make deployment easier, ok. But why should it be easier/faster/better to implement low level communications in Java than in C? Looping around read/write controlled by select or termios IMHO should be easier/faster/better in C. (I understand that a Java developer who is using C not very often will disagree, but just because of personal perferences - which do not matter for rxtx users, because it can be considered an implementation detail). A suited JNI API and implementation IMHO is more powerful. The implementation can call select (or epoll or whatever) before each read/write to let it control timeouts, it could implement both intercharacter and total timeout, maybe also a min threshold or whatever and then have a Java implementation to downgrade this to the InputStream / OutputStream (specialized versions, of course, because at least some SerialInputStream.setTimeout() is needed). In future, I think it would be great if the now internal API to the powerful but `lower-level' JNI functionalities could be defined fixed, documented and `exported' to allow specific implementations (I'm not sure, but I assume that for example some PPP/TCP/IP stack could be better implemented on the JNI interface than on the InputStream-style interface, which, as already told, isn't sufficient anyway). For a version 3.0, why not adding new APIs if it is for good reason? The InputStream stuff isn't useable on it's own, applications have to know that in case of serial I/O setTimeout and whatever has to be called, so where is the problem in offering an appropriate interface (similar as the one used) instead of forcing applications to use the InputStream lookalike that behaves (slightly) differently? If an application relies on control signals, for instance, InputStream won't work anyway. And for those who do not have such requirements (may be most of the users) there of course should the InputStream still be present in a version 3.0. > And you could convert the C that calls read() > etc. to Java in a snap that way (the Java code will be almost exactly > the same with these wrappers!) > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then > call win32 function wrappers (Windows.CreateFile(), > Windows.ReadFile(), ...). But then the `portable' Java code has to know all those platform-specifics - beside potential performance issues due to heaps of calls. > 2) Have separate java implementations for a POSIX serial port and a > Windows serial port, both in Java, sounds a bit funny (`having a portable platform-dependent implementation for each platform in the portable platform-indepenent language') :-) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Aug 17 09:17:09 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 17 Aug 2010 08:17:09 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: My use of RXTX is to distribute it with another Java program (JMRI) RXTX is intensely useful _because_ it works on lots and lots of platforms. When that breaks down, as it has occasionally, and RXTX doesn't work on some specific platform, that's a problem. The last three times this happened, I tried to recompile RXTX to fix what appeared to be relatively simple problems with library versions. This was _not_ a success. I certainly understand that RXTX is a volunteer effort, and that the nitty-gritty of cross-platform compilation is not something that people generally do because they love it. But despite a lot of help from some really strong people, I wasn't able to build a version of RXTX that worked on all existing platforms _plus_ the new compilation. We are therefore currently working with three different sets of RXTX libraries, and there's currently a bug open that will probably require a 4th one. The problem is in compiling the C code. Compiling C code for N platforms is inherently difficult to do when you don't have all N platform's build environments available, and a real pain even when you do. If JNA can live up to it's promise of moving that C code over to Java code, then I think it's a major win. At least I'll be able to compile and distribute it! And if it's easier for me to do, I have to believe it'll be easier for the RXTX team to do it, issue new versions, etc. Bob From Kustaa.Nyholm at planmeca.com Tue Aug 17 10:14:38 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 19:14:38 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com>, Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADC@SRVFIHKIEXB01.pmgroup.local> >My use of RXTX is to distribute it with another Java program (JMRI) >RXTX is intensely useful _because_ it works on lots and lots of >platforms. When that breaks down, as it has occasionally, and RXTX > doesn't work on some specific platform, that's a problem. >The last three times this happened, I tried to recompile RXTX to fix >what appeared to be relatively simple problems with library versions. >This was _not_ a success. Hear hear! > The problem is in compiling the C code. Compiling C code for N >platforms is inherently difficult to do when you don't have all N > platform's build environments available, and a real pain even when you > do. Indeed! >If JNA can live up to it's promise of moving that C code over to Java >code, then I think it's a major win. At least I'll be able to compile >and distribute it! And if it's easier for me to do, I have to believe >it'll be easier for the RXTX team to do it, issue new versions, etc. Well put. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 10:35:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 19:35:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com>, <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> >In short, I think I like the JNI approach as done by rxtx. It >uses native code to handle the native platform specifics. That by itself has no value, as far as I can see. > It can use defines and whatever is needed to make it work even on un*x > systems which may have problems in termios or other > implementations. Platform specific defines are about the only thing one gains from using using 'native' code. But then again, the preferred distribution for any application, from the end user point of view, are compiled executables, so having platform dependencies handled by compile time decisions is bad. > As far as I know, this is common and > implementing serial I/O portable and correctly even today still > is a major challenge Agree. > - best done in C (or C++). Why? >Personally, I think Javas InputStream/OutputStream approach is >not suited for communications. A core problem is the missing > timeout support (boolean avialable(long timeout)) and that > bidirectional I/O might be tricky (to do without multithreading > and without polling), because there is not > `available_or_ready_to_write'. This is true as far as it goes. However we have timeout in rxtx and javacomm and many of us live with it. In any case the spec for rxtx/javacomm is what it is (ie it uses Streams) so we have to live with that in this context. And this of course has nothing to do with JNA/JNI. Surely we could create a new API that would fix these and other semantic issues with javacomm, and why not. However a lot of people use what we have today and would not like to change their code so any new API would be best created as separate API. >But why should it be easier/faster/better to implement low level >communications in Java than in C? Because you don't need to handle/understand two different language runtimes and don't have to have a C tool chain, which as many have testified here is often a major headache. >Looping around read/write >controlled by select or termios IMHO should be >easier/faster/better in C. (I understand that a Java developer >who is using C not very often will disagree, but just because of >personal perferences - which do not matter for rxtx users, >because it can be considered an implementation detail). On theoretical level it is an implementation level but in practice a lot of user are forced to compile the code and need to get into terms with the hell of getting C code to compile and link. > A suited JNI API and implementation IMHO is more powerful. The > implementation can call select (or epoll or whatever) before each > read/write to let it control timeouts, it could implement both > intercharacter and total timeout, maybe also a min threshold or > whatever and then have a Java implementation to downgrade this to > the InputStream / OutputStream (specialized versions, of course, > because at least some SerialInputStream.setTimeout() is needed). What ever you can do with JNI you can do more easily with JNA. I fail to see what are the advantages of implementing things on C. Performance is the only thing that comes to mind but that is an issue that needs to be considered in actual context with calculations and measurements, not with assumption that doing things on C is faster and therefore better. >In future, I think it would be great if the now internal API to > the powerful but `lower-level' JNI functionalities could be > defined fixed, documented and `exported' to allow specific > implementations (I'm not sure, but I assume that for example some > PPP/TCP/IP stack could be better implemented on the JNI interface > than on the InputStream-style interface, which, as already told, > isn't sufficient anyway). If such a cross platform C library existed it would be great and we would not need rxtx at all (except of course the existing code base) and could call directly that library using JNI or JNA. >For a version 3.0, why not adding new APIs if it is for good > reason? Why not create a new project for that? Let's keep rxtx what it is ie a replacement for javacomm. >But then the `portable' Java code has to know all those >platform-specifics - What is the objection to that? Either the C or Java side needs to do/know this and as demonstrated (IMO) doing it on the Java side has a lot of advantages. >beside potential performance issues due to heaps of calls. This is so loaded with assumptions that I won't bother. >> 2) Have separate java implementations for a POSIX serial port and a >> Windows serial port, both in Java, >sounds a bit funny (`having a portable platform-dependent >implementation for each platform in the portable >platform-indepenent language') :-) Yeah, I see the irony but to me it actually makes a lot of sense. br Kusti From adrian.crum at yahoo.com Tue Aug 17 12:16:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 17 Aug 2010 11:16:00 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> Message-ID: <102598.14191.qm@web63101.mail.re1.yahoo.com> --- On Tue, 8/17/10, Kustaa Nyholm wrote: > What ever you can do with JNI you can do more easily with > JNA. > I fail to see what are the advantages of implementing > things on C. Let's make one thing perfectly clear - using JNA instead of JNI will NOT make things easier. You're simply moving code up the stack from C to Java - but it will still be the same code. Instead of trying to convince everyone how easy JNA is based on a simple printf example in a Wiki - why don't you prove it? Implement RXTX using JNA and make us all believers. Until then, you're just making things up. -Adrian From bschlining at gmail.com Tue Aug 17 12:40:20 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 17 Aug 2010 11:40:20 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: > > > > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi > > Tried to find some documentation or tutorial but couldn't ...so what is the > difference / advantage? > > Does it work on all the platforms where JNA works? > I think JRuby is now using JFFI for native code interaction; so yes it should be very cross-platform. The author of JFFI is a contributor to both JRuby and JNA (See http://www.mail-archive.com/dev at jruby.codehaus.org/msg03607.html) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucio at sulweb.org Tue Aug 17 15:14:43 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 23:14:43 +0200 Subject: [Rxtx] JNA alternative (was: rxtx moving from JNI to JNA (was Re: About JRE crashes)) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: <201008172314.43315.lucio@sulweb.org> August 17 2010 16:55:36, Steffen DETTMER wrote: > just because of > personal perferences - which do not matter for rxtx users, > because it can be considered an implementation detail). I agree that users don't really care about how things work, but only until they are forced to understand them in order to have a patch applied. Personally I like the JNA idea, but there is at least one other less intrusive solution to the problem, that is to stay with JNI and to provide unofficial, unsupported, nightly (or weekly/monthly) cvs snapshot builds that include all the somewhat tested patches so far. That way users can try one of the snapshot builds instead of building from source themselves. What's the meaning of "somewhat tested patches"? Well, maybe any patch downloadable from a "resolved" bug report (but bug 144 is still "NEW" while a patch does exist and seems to work, so we have to decide the exact rules that make patches go into the snapshot build). The resulting build will be unsupported after all, just the same way a compilation done by a casual user is unofficial and unsupported. When the user knows a particurlar patch solves his problems, he can (if he likes) grab cvs sources, apply only that one patch he needs, set up a build environment and compile sources himself: at least the user will know in advance he is not wasting hours of time to apply a possibly useless-for-him patch. Or he can live with the unofficial and unsupported snapshot if he finds it works for him. Let me know what you think about my proposal. Since in the current situation I'm forced to set up a build environment for linux only to test the patch attached to bug 144 on linux, I could provide unofficial and unsupported builds for linux platforms on a regular basis if someone helps me spot the patches and distinguish between the "somewhat tested" ones and the others. From Kustaa.Nyholm at planmeca.com Wed Aug 18 02:52:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 11:52:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: > Let's make one thing perfectly clear - using JNA instead of JNI will NOT make > things easier. Depends on what 'things' you are talking about and in what context and for who it does not make things easier. But it is difficult to see your point of view ie why would it not be easier if you don't have to deal with two tool chains and languages. > You're simply moving code up the stack from C to Java - but it > will still be the same code. Of course the code is the same, but the practicalities are hugely different. > Instead of trying to convince everyone how easy JNA is based on a simple > printf example in a Wiki - why don't you prove it? > Implement RXTX using JNA and make us all believers. I have no need to convince you or anyone else, I'm happy with rxtx the way it is at the moment. As long as I can get a pre-compiled binary that just works for the platforms that I need it for, it is all that I need. I was talking in the context of someone's suggestion that a re-write is contemplated and was merely suggesting that in that case it might make sense to to get rid of the C stuff and the associated practical problems. > Until then, you're just making things up. I don't think that was a gentlemanly remark worth of a reply. br Kusti From george.dma at gmail.com Wed Aug 18 03:31:44 2010 From: george.dma at gmail.com (George H) Date: Wed, 18 Aug 2010 12:31:44 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: On Wed, Aug 18, 2010 at 11:52 AM, Kustaa Nyholm wrote: > >> Instead of trying to convince everyone how easy JNA is based on a simple >> printf example in a Wiki - why don't you prove it? >> Implement RXTX using JNA and make us all believers. > > I have no need to convince you or anyone else, I'm happy with rxtx the > way it is at the moment. As long as I can get a pre-compiled binary that > just works for the platforms that I need it for, it is all that I need. > > I was talking in the context of someone's suggestion that a re-write is > contemplated and was merely suggesting that in that case it might make > sense to to get rid of the C stuff and the associated practical problems. > Yeah it seems that context got taken out of hand. Adrian Crum was talking about re-write here http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html There is still the part of performance issue mentioned by many. And this one got lost from the thread since the subject changed http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html If you are happy with how RXTX is then continue to be happy, provide input and let developers be open to experimentation. It seems you are pretty adamant about using JNA. It seems to be good for a lot of things but maybe not for RXTX. The only way i can see JNA being used productively in RXTX is to be the proxy pattern between the Java code and the Native rxtx code. From what I read on this list and from looking at the native source code, it is likely that a performance hit will be a big issue if the code is moved up the stack to java. Should some people disagree then they should do a performance test with a test lib where they shifted some of the code up the stack. >> Until then, you're just making things up. > > I don't think that was a gentlemanly remark worth of a reply. > Don't take it personally, we are all computer people, we trust evidence based on experiments and benchmarks more than people's claims. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Wed Aug 18 04:07:10 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 18 Aug 2010 20:07:10 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <102598.14191.qm@web63101.mail.re1.yahoo.com> References: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: <14743-1282126034-652758@sneakemail.com> The main difference is that your wrapper for, say, select() is generated by JNA and doesnt have to be hand coded in JNI with C/C++. In my mind thats an advantage and in deed does make things easier. But as said, there might be other reasons why not to use it, maybe the wrappers are not as nice? What does JNA do with pointers to structs passed into functions? Do you have to deal with raw memory in Java? (you can avoid both in hand written JNI wrappers). How does it deal with os functions like ReadFile() when doing async I/O where the OS holds on to a buffer after the function returns? I have written quite a fair bit of Jni code lately, and these are the things that can make your life difficult if not handled correctly. But youre right, eventually someone has to go out and try it for rxtx ;-) Uwe On 18/08/2010 4:25 AM, "Adrian Crum adrian.crum-at-yahoo.com |rxtx.orgmailing list/Example Allow|" < drvwbrbtut at sneakemail.com> wrote: --- On Tue, 8/17/10, Kustaa Nyholm wrote: > What ever you can do with J... Let's make one thing perfectly clear - using JNA instead of JNI will NOT make things easier. You're simply moving code up the stack from C to Java - but it will still be the same code. Instead of trying to convince everyone how easy JNA is based on a simple printf example in a Wiki - why don't you prove it? Implement RXTX using JNA and make us all believers. Until then, you're just making things up. -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://ma... -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Wed Aug 18 04:07:10 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 18 Aug 2010 20:07:10 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <14740-1282126020-515157@sneakemail.com> Have a look at jpathwatch, it is exactly implemented like that. The only thing thats different to what's dicussed here is that it's low level OS wrappers are implemented in JNI instead of JNA (with typically 10 lines of C++ code each) But whatever your approach for the wrapper (and I see reasons for and against JNA), it shows how simple it can be to implement platform specific code in java when you only do in native code what you absolutely have to. Cheers, Uwe On 18/08/2010 4:49 AM, "Brian Schlining bschlining-at-gmail.com |rxtx.orgmailing list/Example Allow|" < 5j55m8uw1t at sneakemail.com> wrote: > > > > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi > > Tried to find so... I think JRuby is now using JFFI for native code interaction; so yes it should be very cross-platform. The author of JFFI is a contributor to both JRuby and JNA (See http://www.mail-archive.com/dev at jruby.codehaus.org/msg03607.html) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Wed Aug 18 04:14:15 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 18 Aug 2010 12:14:15 +0200 Subject: [Rxtx] what's the status of these new patches Message-ID: <4C6BB277.1050400@lfarkas.org> hi, i'm just check the cvs server and there is nothing changed on it in the last few months. is the patches recently appear on this list are dropped or use som kind of other version control system or just not yet applied? thanks. regards. -- Levente "Si vis pacem para bellum!" From adrian.crum at yahoo.com Wed Aug 18 07:15:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 06:15:43 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <3522.82736.qm@web63106.mail.re1.yahoo.com> --- On Wed, 8/18/10, George H wrote: > Kustaa Nyholm > > wrote: > > > >> Instead of trying to convince everyone how easy > JNA is based on a simple > >> printf example in a Wiki - why don't you prove > it? > >> Implement RXTX using JNA and make us all > believers. > > > > I have no need to convince you or anyone else, I'm > happy with rxtx the > > way it is at the moment. As long as I can get a > pre-compiled binary that > > just works for the platforms that I need it for, it is > all that I need. > > > > I was talking in the context of someone's suggestion > that a re-write is > > contemplated and was merely suggesting that in that > case it might make > > sense to to get rid of the C stuff and the associated > practical problems. > > > > Yeah it seems that context got taken out of hand. > Adrian Crum was talking about re-write here > http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html > > There is still the part of performance issue mentioned by > many. And > this one got lost from the thread since the subject > changed > http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html Thank you for bringing this back to the original subject. I tried to fix the JRE crash issue, but I gave up because of two main reasons: the C code is unnecessarily complicated, and error return codes are being ignored. The basic problem I ran into is: Java code calls native method A, native method A calls native method B, and native method B calls native method C. Method C encounters an error and returns an error code to method B. Method B ignores the returned error code and returns success to method A. Java code doesn't know there was an error and continues operating like nothing is wrong. I started fixing the existing code so error codes would be propagated back to Java, but then what do I do with the error code when it's time to return to Java? The original javax.comm specification doesn't allow for errors returned from native code. I also ran into places where threads are being started in native code - which is a bad idea because you could lose control over the thread after you return to Java. Then I found thread synchronization problems in the code... So, I decided to rewrite the library. So far I have the Java code rewritten, and I am currently working on the Windows native code. Once I have it all working, I will make a formal proposal for a new version, post the code, and we can take it from there. I believe once the code is simplified, many of the quirky bugs will go away, deploying native code will be easier, and any discussions about switching to JNA will be moot. -Adrian From george.dma at gmail.com Wed Aug 18 07:38:30 2010 From: george.dma at gmail.com (George H) Date: Wed, 18 Aug 2010 16:38:30 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <3522.82736.qm@web63106.mail.re1.yahoo.com> References: <3522.82736.qm@web63106.mail.re1.yahoo.com> Message-ID: On Wed, Aug 18, 2010 at 4:15 PM, Adrian Crum wrote: > --- On Wed, 8/18/10, George H wrote: >> Kustaa Nyholm >> >> wrote: >> > >> >> Instead of trying to convince everyone how easy >> JNA is based on a simple >> >> printf example in a Wiki - why don't you prove >> it? >> >> Implement RXTX using JNA and make us all >> believers. >> > >> > I have no need to convince you or anyone else, I'm >> happy with rxtx the >> > way it is at the moment. As long as I can get a >> pre-compiled binary that >> > just works for the platforms that I need it for, it is >> all that I need. >> > >> > I was talking in the context of someone's suggestion >> that a re-write is >> > contemplated and was merely suggesting that in that >> case it might make >> > sense to to get rid of the C stuff and the associated >> practical problems. >> > >> >> Yeah it seems that context got taken out of hand. >> Adrian Crum was talking about re-write here >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html >> >> There is still the part of performance issue mentioned by >> many. And >> this one got lost from the thread since the subject >> changed >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html > > Thank you for bringing this back to the original subject. > > I tried to fix the JRE crash issue, but I gave up because of two main reasons: the C code is unnecessarily complicated, and error return codes are being ignored. > > The basic problem I ran into is: Java code calls native method A, native method A calls native method B, and native method B calls native method C. Method C encounters an error and returns an error code to method B. Method B ignores the returned error code and returns success to method A. Java code doesn't know there was an error and continues operating like nothing is wrong. > > I started fixing the existing code so error codes would be propagated back to Java, but then what do I do with the error code when it's time to return to Java? The original javax.comm specification doesn't allow for errors returned from native code. > > I also ran into places where threads are being started in native code - which is a bad idea because you could lose control over the thread after you return to Java. Then I found thread synchronization problems in the code... > > So, I decided to rewrite the library. So far I have the Java code rewritten, and I am currently working on the Windows native code. Once I have it all working, I will make a formal proposal for a new version, post the code, and we can take it from there. > > I believe once the code is simplified, many of the quirky bugs will go away, deploying native code will be easier, and any discussions about switching to JNA will be moot. > > -Adrian > I'm glad that you are taking the initiative to fix these problems and we're all happy because it will benefit us, or at least not yet for me since I am a Linux user :) I do take your word for it about re-writing and it seems you have jump-started the process and the other devs are getting their interest back. btw, I don't know about the javax.comm specs but I would certainly want errors to be returned from native code if it was me. Imagine I call a function from a native library and somewhere inside something bad happens that causes my action to yield an undesirable result. I would want to know that. That is to say that if the result is undesirable then I would want to know, if it is some lower error that maybe can be ignored or occurs anyways for some reason but does not affect the result of what I want, perhaps I wouldn't want that error to be propagated back up. It would cause the "I get an error but it worked" response. Propagating errors... like throwing an exception back up to Java or returning a value (ie, -1 or null or false) indicating an error ? This would need a consensus of the you and the main devs. On a side note, I am happy to see activity in this project :) -- George H george.dma at gmail.com From HowardZ at howardz.com Wed Aug 18 08:27:11 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 18 Aug 2010 10:27:11 -0400 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: References: Message-ID: <4C6BEDBF.9040703@howardz.com> Hi, I have been reading the comments about JNA, and it sounds interesting. It looks like - at least on Windows - that all of rxtx can be written in Java with windows calls going directly to JNA to be invoked on Windows. Whether this will really work out for the complex structures passed to some windows calls remains to be seen. The Java code would need to ask the Java RTE which operating system it is running on, and then load appropriate operating system provided dll/so files, and use the appropriate operating system system calls. Sounds like it will eliminate ALL the C-code - not one line of C code will be needed, greatly simplify the rxtx building process. There would be absolutely no need to build any dll nor so file. There would be no need to have available a Windows PC, and Mac, several Linux PCs to build all the dll/so files. (However, one will need these PCs available to thoroughly test that a change - to assure it works on all these platforms.) These are just my thoughts, as I have never used JNA. It sounds desirable. Howard From adrian.crum at yahoo.com Wed Aug 18 09:06:26 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 08:06:26 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <4C6BEDBF.9040703@howardz.com> Message-ID: <819913.60999.qm@web63102.mail.re1.yahoo.com> --- On Wed, 8/18/10, HowardZ at howardz.com wrote: > Hi, > > I have been reading the comments about JNA, and it sounds > interesting. > > It looks like - at least on Windows - that all of rxtx can > be written in Java with windows calls going directly to JNA > to be invoked on Windows.? Whether this will really > work out for the complex structures passed to some windows > calls remains to be seen. > > The Java code would need to ask the Java RTE which > operating system it is running on, and then load appropriate > operating system provided dll/so files, and use the > appropriate operating system system calls. One thing to keep in mind is the RXTX jar file will include code for ALL supported platforms, not just the one you want to run it on. Unless you want to have a separate jar file for each environment - which exchanges one problem for another. Instead of separate native libs for each environment, you now have separate jars for each environment. I don't know how other members of the community feel about library size, but for me I want RXTX to be as small as possible - so I can have more memory for my application. RXTX on JNA will be huge - because all of the C code will be moved to Java. And as far as eliminating the need to have a separate lib in addition to RXTX - don't forget your application will have to include the JNA lib. Again, you have simply exchanged one problem with another. > Sounds like it will eliminate ALL the C-code - not one line > of C code will be needed, greatly simplify the rxtx building > process.? There would be absolutely no need to build > any dll nor so file.? There would be no need to have > available a Windows PC, and Mac, several Linux PCs to build > all the dll/so files. Any problems anyone might be having compiling the native libs is probably due to the somewhat disorganized layout of the project - it's not because the native libs are written in C. Once I got the project's resources figured out, I was able to get the Windows code to compile easily. I would suggest better project layout and better documentation will improve things a lot more than a switch to JNA. -Adrian From adrian.crum at yahoo.com Wed Aug 18 09:14:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 08:14:43 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <628799.64371.qm@web63107.mail.re1.yahoo.com> --- On Wed, 8/18/10, George H wrote: > Adrian Crum > wrote: > > --- On Wed, 8/18/10, George H > wrote: > >> Kustaa Nyholm > >> > >> wrote: > >> > > >> >> Instead of trying to convince everyone > how easy > >> JNA is based on a simple > >> >> printf example in a Wiki - why don't you > prove > >> it? > >> >> Implement RXTX using JNA and make us all > >> believers. > >> > > >> > I have no need to convince you or anyone > else, I'm > >> happy with rxtx the > >> > way it is at the moment. As long as I can get > a > >> pre-compiled binary that > >> > just works for the platforms that I need it > for, it is > >> all that I need. > >> > > >> > I was talking in the context of someone's > suggestion > >> that a re-write is > >> > contemplated and was merely suggesting that > in that > >> case it might make > >> > sense to to get rid of the C stuff and the > associated > >> practical problems. > >> > > >> > >> Yeah it seems that context got taken out of hand. > >> Adrian Crum was talking about re-write here > >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html > >> > >> There is still the part of performance issue > mentioned by > >> many. And > >> this one got lost from the thread since the > subject > >> changed > >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html > > > > Thank you for bringing this back to the original > subject. > > > > I tried to fix the JRE crash issue, but I gave up > because of two main reasons: the C code is unnecessarily > complicated, and error return codes are being ignored. > > > > The basic problem I ran into is: Java code calls > native method A, native method A calls native method B, and > native method B calls native method C. Method C encounters > an error and returns an error code to method B. Method B > ignores the returned error code and returns success to > method A. Java code doesn't know there was an error and > continues operating like nothing is wrong. > > > > I started fixing the existing code so error codes > would be propagated back to Java, but then what do I do with > the error code when it's time to return to Java? The > original javax.comm specification doesn't allow for errors > returned from native code. > > > > I also ran into places where threads are being started > in native code - which is a bad idea because you could lose > control over the thread after you return to Java. Then I > found thread synchronization problems in the code... > > > > So, I decided to rewrite the library. So far I have > the Java code rewritten, and I am currently working on the > Windows native code. Once I have it all working, I will make > a formal proposal for a new version, post the code, and we > can take it from there. > > > > I believe once the code is simplified, many of the > quirky bugs will go away, deploying native code will be > easier, and any discussions about switching to JNA will be > moot. > > > > -Adrian > > > > I'm glad that you are taking the initiative to fix these > problems and > we're all happy because it will benefit us, or at least not > yet for me > since I am a Linux user :) > > I do take your word for it about re-writing and it seems > you have > jump-started the process and the other devs are getting > their interest > back. > > btw, I don't know about the javax.comm specs but I would > certainly > want errors to be returned from native code if it was me. > Imagine I > call a function from a native library and somewhere inside > something > bad happens that causes my action to yield an undesirable > result. I > would want to know that. > > That is to say that if the result is undesirable then I > would want to > know, if it is some lower error that maybe can be ignored > or occurs > anyways for some reason but does not affect the result of > what I want, > perhaps I wouldn't want that error to be propagated back > up. It would > cause the "I get an error but it worked" response. > > Propagating errors... like throwing an exception back up to > Java or > returning a value (ie, -1 or null or false) indicating an > error ? The approach I took was to exploit a loophole in the javax.comm API. It states that if any CommPort methods are called when the port is closed, an IllegalStateException should be thrown (a part of the javax.comm API RXTX does not follow btw). So, if any low-level errors occur, an IOException is passed back to the RXTX Java code, and the Java code catches that exception and closes the port. Any future method calls on that port will generate an IllegalStateException - so the application can take steps to recover. -Adrian From Bob_Jacobsen at lbl.gov Wed Aug 18 09:26:12 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 18 Aug 2010 08:26:12 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <819913.60999.qm@web63102.mail.re1.yahoo.com> References: <819913.60999.qm@web63102.mail.re1.yahoo.com> Message-ID: <4E9DD51E-5E9F-4BE6-AC87-29D619039B3D@lbl.gov> On Aug 18, 2010, at 8:06 AM, Adrian Crum wrote: > I don't know how other members of the community feel about library > size, but for me I want RXTX to be as small as possible - so I can > have more memory for my application. RXTX on JNA will be huge - > because all of the C code will be moved to Java. What platform are you using it on? The classloaders on the ones I'm familiar with only load classes that are referenced. No memory space is used for classes that aren't referenced. It's possible for un- needed references to creep in, but that's rather straightforward to check for and fix. > And as far as eliminating the need to have a separate lib in > addition to RXTX - don't forget your application will have to > include the JNA lib. Again, you have simply exchanged one problem > with another. You underestimate the problem with native libs. With the current RXTX structure, JMRI has to distribute two separate Windows DLLs, and make sure the right one gets used; three different Linux .so's (ditto), and and four different Mac .jnilibs (ditto, and even harder due to version- dependence). The run-time scripting needed for that takes a lot of work to maintain. That's quite different from having one more .jar file to include (or even merge into a common .jar). It might be possible to build a single RXTX distribution that would work, without having to select different native libraries, across 64 vs 32 bit differences, architecture differences, OS version differences, etc, but I certainly haven't been able to do it. > Any problems anyone might be having compiling the native libs is > probably due to the somewhat disorganized layout of the project - > it's not because the native libs are written in C. Once I got the > project's resources figured out, I was able to get the Windows code > to compile easily. I would suggest better project layout and better > documentation will improve things a lot more than a switch to JNA. Did you build for both 32 and 64 bit Windows? Let alone the various Mac and Linux variants? RXTX is valuable _because_ it's cross-platform. That value is lost when an RXTX version doesn't actually work on multiple platforms. Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From john at buglabs.net Wed Aug 18 09:27:55 2010 From: john at buglabs.net (John Connolly) Date: Wed, 18 Aug 2010 11:27:55 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: On Tue, Aug 17, 2010 at 8:43 AM, Kustaa Nyholm wrote: > > > Has anyone tried using JNA to gain access to web cams? > > Not a web cam but one of these: > > > http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 > > took me about half an hour to convert the C-headers to a JNA interface and > it worked no problem. > What C-headers? From what API? Are they specific to that model of camera? I like v4l4j but the GPL licensing is incompatible with other ASL-based licensed software I use. > > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ______________________ John Connolly Software Developer Bug Labs 598 Broadway, 4th Floor New York, NY 10012-3206 646.723.9258 jconnolly @ irc.freenode.net/#buglabs -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 18 09:29:48 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 18:29:48 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <628799.64371.qm@web63107.mail.re1.yahoo.com> Message-ID: > > The approach I took was to exploit a loophole in the javax.comm API. It states > that if any CommPort methods are called when the port is closed, an > IllegalStateException should be thrown (a part of the javax.comm API RXTX does > not follow btw). So, if any low-level errors occur, an IOException is passed > back to the RXTX Java code, and the Java code catches that exception and > closes the port. Any future method calls on that port will generate an > IllegalStateException - so the application can take steps to recover. > > -Adrian I'm not against this but strictly speaking the javadoc says: "Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown." So this to me implies that 'closed' means that the close-method has been called, not that the port is de-facto closed because of some internal error. However, if the port is de-facto close then it would be logical to throw IllegalStateException, not to mention that it would be useful. So I'm supporting this behavior. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 18 09:45:38 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 18:45:38 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <819913.60999.qm@web63102.mail.re1.yahoo.com> Message-ID: > > I don't know how other members of the community feel about library size, but > for me I want RXTX to be as small as possible - so I can have more memory for > my application. RXTX on JNA will be huge - because all of the C code will be > moved to Java. That (calling it huge) is jumping the gun because we do not have a JNA implementation, not even any idea of its size. And the definition of 'huge' depends on individual circumstance. Standard edition JRE was +50MB the last time I checked. jna.jar is 928 kB. > > Any problems anyone might be having compiling the native libs is probably due > to the somewhat disorganized layout of the project - it's not because the > native libs are written in C. Simply not true, a better make/build process would certainly help the C stuff, but even the best organized builds seem to have compile problems. Witness the endless requests for help to build this or that open source project. Writing cross platform C is very, very difficult. For anyone interested I suggest reading the libusb list archives and seeing how much work they had to put in to get it to compile on all their supported platforms. But I'm not saying JNA is panacea, not by a long shot. There are certainly problems (and solutions) associated with the size of OS API structures that depend on the architecture and especially with the constants (#defines) that you pass to the OS. > Once I got the project's resources figured out, > I was able to get the Windows code to compile easily. Good for you. Did you start with a virgin Windows installation with no tools etc installed? > I would suggest better > project layout and better documentation will improve things a lot more than a > switch to JNA. > Sure, better project layout and better documentation can go a long way but without us testing the JNA approach saying it 'will improve things a lot more than JNA ' is just, to quote an earlier entry on this list, 'making things up'. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 18 09:49:13 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 18:49:13 +0300 Subject: [Rxtx] JNA 4 web cams In-Reply-To: Message-ID: > What C-headers?? From what API?? Are they specific to that model of camera?? I > like v4l4j but the GPL licensing is incompatible with other ASL-based licensed > software I use > > That camera comes with its own API/DLL and has a header file for that. I simply converted this to a JNA class and all was Hunky-dory. Since then I've learned about JNAerator that will do it for me and when I just tested it on termios.h, the conversion was a sub second thing! br Kusti From adrian.crum at yahoo.com Wed Aug 18 10:01:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 09:01:37 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: Message-ID: <221632.76425.qm@web63101.mail.re1.yahoo.com> --- On Wed, 8/18/10, Kustaa Nyholm wrote: > > I would suggest better > > project layout and better documentation will improve > things a lot more than a > > switch to JNA. > > > > Sure, better project layout and better documentation can go > a long way but > without us testing the JNA approach saying it 'will improve > things a lot > more than JNA ' is just, to quote an earlier entry on this > list, 'making > things up'. Touche' ;-) -Adrian From rvraaphorst at gmail.com Wed Aug 18 11:27:05 2010 From: rvraaphorst at gmail.com (Ronald Raaphorst, van) Date: Wed, 18 Aug 2010 19:27:05 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <221632.76425.qm@web63101.mail.re1.yahoo.com> References: <221632.76425.qm@web63101.mail.re1.yahoo.com> Message-ID: <4E4649E7-3C9F-48B3-B640-48E5C85ED5AA@gmail.com> I cant comment on the technical issues but having a single cross platform jar is very easy to distribute with the application and would make it far easier to create a decent install app imho (i am using rxtx for a cross platform app and i already had trouble getting it all to work on my mbp with snow leopard 1.6) I also would very much like a nightly build system with all sorts of tests so we can easily add patches on a regular basis and be sure the whole lib keeps functioning properly It cant be that hard to script a nightly checkout and run all tests? Isnt this what build servers/apps like hudson are made for? Ronald On 18 aug. 2010, at 18:01, Adrian Crum wrote: > --- On Wed, 8/18/10, Kustaa Nyholm wrote: >>> I would suggest better >>> project layout and better documentation will improve >> things a lot more than a >>> switch to JNA. >>> >> >> Sure, better project layout and better documentation can go >> a long way but >> without us testing the JNA approach saying it 'will improve >> things a lot >> more than JNA ' is just, to quote an earlier entry on this >> list, 'making >> things up'. > > Touche' > > ;-) > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Aug 18 11:45:19 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 18 Aug 2010 19:45:19 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <628799.64371.qm@web63107.mail.re1.yahoo.com> References: <628799.64371.qm@web63107.mail.re1.yahoo.com> Message-ID: Hi, 2010/8/18 Adrian Crum adrian.crum at yahoo.com > > > The approach I took was to exploit a loophole in the javax.comm API. It > states that if any CommPort methods are called when the port is closed, an > IllegalStateException should be thrown (a part of the javax.comm API RXTX > does not follow btw). So, if any low-level errors occur, an IOException is > passed back to the RXTX Java code, and the Java code catches that exception > and closes the port. Any future method calls on that port will generate an > IllegalStateException - so the application can take steps to recover. > > -Adrian > > > But there is very simple solution, which in my opinion is a good programming practice as well. In my software (Java, Windows) EACH call to Comm functions is AFTER checking if port is yet open... Therefore I can easy react on any problem with hardware or software around COM, I am reading here about problems with RXTX, but I have had only one - close problem because of threads sync and not proper RXTX configuration, specific for platform. I have solved it in Java part of the app. USB/VCP dongle diconnecting is secured ONLY on the Java app side (not RXTX) as well, and works. C code stays untouched in W/M/L... Does my VCP drivers are so good or ....? Regards Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 18 11:45:21 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 20:45:21 +0300 Subject: [Rxtx] termios.h defines ... JNA related Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE2@SRVFIHKIEXB01.pmgroup.local> Hi, toying with the JNA approach, one of the issues is how to handle the #defines like B19200 etc etc. It is of course trivial to have them as constants on the Java side, but there are a few details that will affect how this is best approached. Like: On Mac OS X B19200 has the value on 19200 where as on one Linux it has the value of 16. How much the different Linux constants differ or can we assume that across Linux:es they are the same? The size of some fields in 'struct termios' is size_t according to POSIX, which makes them depend on architecture. Handling this is trivial with JNA but what about the values in those fields? Is it conceivable that the values are different depending on architecture (on the same OS)? Like Mac OS X has i386 (32 bit) ppc (32 bit) and x86_64 (64 bit) architecture and I presume the size of for example c_flags in termios struct is different depending on the architecture (maybe it is not?) but what about the values? br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 18 11:51:43 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 20:51:43 +0300 Subject: [Rxtx] Non standard baudrates...related to JNA Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE3@SRVFIHKIEXB01.pmgroup.local> Now, again considering the JNA approach, there is the issue of passing the baudrates from Java to OS. The Java doc for SerialPort.setSerialPortParams says: If the baudrate passed in by the application is unsupported by the driver, the driver will throw an UnsupportedCommOperationException Now, if and when the interface to OS on unix like system would most likely be based on termios.h/POSIX approach, how would this be handled? One scenario is that the code would check if the value passed to setSerialPortParams for baudrate is one of the standard POSIX baudrates and if so use the corresponding Bxxx from termios.h for that platform and if not , just pass the value directly to the OS. This should support both standard and non standard baudrates (at least setting them, querying could be more tricky). For example Mac OS uses the baudrate value directly whereas Linux uses some magic values. What is the rxtx stand on this? br Kusti From tjarvi at qbang.org Wed Aug 18 11:30:19 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Aug 2010 11:30:19 -0600 (MDT) Subject: [Rxtx] Building and Testing In-Reply-To: <4E4649E7-3C9F-48B3-B640-48E5C85ED5AA@gmail.com> References: <221632.76425.qm@web63101.mail.re1.yahoo.com> <4E4649E7-3C9F-48B3-B640-48E5C85ED5AA@gmail.com> Message-ID: On Wed, 18 Aug 2010, Ronald Raaphorst, van wrote: > I cant comment on the technical issues but having a single cross > platform jar is very easy to distribute with the application and would > make it far easier to create a decent install app imho > > (i am using rxtx for a cross platform app and i already had trouble > getting it all to work on my mbp with snow leopard 1.6) > > I also would very much like a nightly build system with all sorts of > tests so we can easily add patches on a regular basis and be sure the > whole lib keeps functioning properly It cant be that hard to script a > nightly checkout and run all tests? Isnt this what build servers/apps > like hudson are made for? > Getting tests going with Serial Loopback connections in automated environments isn't easy from my experience. That said, having tests with RXTX is a great idea. Ideally, people could use it to track the progress of efforts like JNA attempts. It does seem like there should be a better way to get rxtx builds done. The native and java code combination adds many requirements to what a build cluster needs to provide. I have access to a test suite at work that exercises the basics of RXTX which is run before putting the code into CVS. It isn't a simple process and the test suite isn't easily shared at this time. The big drawback is that it communicates over loopback. The settings are always able to communicate leaving little room for negative tests. Earlier I mentioned a meeting was taking place yesterday regarding building and testing. I've worked out how to get builds and tests done in two batch jobs in some clusters at work which will be good for ~weekly checkpoints but it can't be automated at this point for nightly builds. I can at least share those libraries and the results of the tests. Its going to take a couple days to get everything setup in the cluster but thats next on my plate. I encourage people to explore other options as well. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 18 11:40:28 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Aug 2010 11:40:28 -0600 (MDT) Subject: [Rxtx] Non standard baudrates... In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE3@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE3@SRVFIHKIEXB01.pmgroup.local> Message-ID: On Wed, 18 Aug 2010, Kustaa Nyholm wrote: > Now, again considering the JNA approach, there is the issue of passing > the baudrates from Java to OS. > > > The Java doc for SerialPort.setSerialPortParams says: > > If the baudrate passed in by the application is unsupported by the > driver, the driver will throw an UnsupportedCommOperationException > > > Now, if and when the interface to OS on unix like system would most likely be based on termios.h/POSIX approach, > how would this be handled? > > One scenario is that the code would check if the value passed to setSerialPortParams for baudrate is one > of the standard POSIX baudrates and if so use the corresponding Bxxx from termios.h for that platform and > if not , just pass the value directly to the OS. This should support both standard and non standard baudrates > (at least setting them, querying could be more tricky). For example Mac OS uses the baudrate value directly > whereas Linux uses some magic values. > > What is the rxtx stand on this? > The initial reason support for nonstandard baudrates was in rxtx is that I didn't know it was not part of POSIX until I looked at BSD/Solaris/.... I think I saw some discussion that POSIX didn't exclude specific baudrates but the magic number implementation wasnt right. The general interpretation was heading down the same direction you mention Mac OS X does. The right thing to do going forward is to satisfy the needs of people that have a requirement for 'nonstandard' baudrates but provide the support in a standard way (look at what has gone on in Mac OS X/Linux since ~2001). -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Aug 18 23:42:07 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 19 Aug 2010 08:42:07 +0300 Subject: [Rxtx] Default port settings. Message-ID: The javadoc for SerialPort.setSerialPortParams says: "DEFAULT: 9600 baud, 8 data bits, 1 stop bit, no parity" but this makes no sense in the context of that method. So how is this spec interpreted or is it ignored? Is this an implication that a SerialPort that has been opened via CommPortIdentifier.open() but for which setSerialPortParams has not been called defaults to these settings? What does rxtx SerialPort do? What about Sun's SerialPort? If the port defaults to anything, then it is of course easier on the SerialPort code because it never has to convert magic internal numbers to javacomm constants. br Kusti From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going back to the events - I have had speed problems on notebooks, not on my development machine and something more - I don't remember exactly what the problems were. Please post the working code, as you have promised, I will copy it to my RXTX repository for future use :) Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Sat Aug 7 06:11:31 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Sat, 7 Aug 2010 14:11:31 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi, can you tell us some kind of estimate when will be the outstanding patches applied and when we can expect a new release? thanks. On Thu, Aug 5, 2010 at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is > working for many people. ?Just make sure you get on the right branch in CVS > as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a > 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. ?The bug > tracker is a good place to start and just paste a link here for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> >>>> problems that have been reported in the bug tracker. >>> >>> They >>>> >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> >>> code >>>> >>>> fixes for individual problems to the list for group >>>> review.? Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> >>> everything >>>> >>>> else along with switching from CVS because....? If >>> >>> you >>>> >>>> have a clear fix for a clear problem with no side >>> >>> effects, >>>> >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion.? They are to help people identify known >>> >>> issues >>>> >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 > > -- ? Levente? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? "Si vis pacem para bellum!" From n.zrelli at tu-bs.de Sat Aug 7 14:34:58 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Sat, 07 Aug 2010 22:34:58 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: <4C5DC372.4070304@tu-bs.de> Hi Mariusz, Funny methode with the generation of exception with data. :-) I have found your message in the archive of 2009 November but unfortunately I can't read the java source code. Regards, Nejd Am 06.08.2010 19:26, schrieb M.Dec-GMail: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz > From klaine8 at gmail.com Sat Aug 7 15:21:37 2010 From: klaine8 at gmail.com (Kari Laine) Date: Sun, 8 Aug 2010 00:21:37 +0300 Subject: [Rxtx] Help understanding char input on linux kterm and other things Message-ID: Hi All, this is my first post to this list. I am learning Java in hope to produce multi platform software for certain Byvac's hardware. http://www.byvac.com Especially I am trying to port Arduino IDE (that's where I found about this rxtx) to BV513 (PIC board). Other is the multiIO card BV4626, which uses escape sequences to communicate. Could someone tell me how can I read keyboard input "raw" with Java program. Now it seems the Enter key is not read with System.in. Also escape key is not available. I know this has something to do with how terminal program works. Any web links where to learn more? I know it is possible because minicom works - how it does that? Are there any free GPL implementation of RS232 terminal program implemented in Java available? Sorry about this stupid post. Now when I look it it has not very much with RXTX to do...any other Java lists? Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer From adrian.crum at yahoo.com Sun Aug 8 15:26:39 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 14:26:39 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <29432.44536.qm@web63104.mail.re1.yahoo.com> I tried registering for the bug tracker using three different email addresses on three different mail servers - no luck. My password never arrived. I need to get patches submitted so I can move on to other things, so I'll try attaching them here. Attached is a patch that fixes some issues with RxTxCommDriver.java: 1. Fixed the gnu.io.rxtx.properties code that didn't work. The registerSpecifiedPorts method treated the java.ext.dirs system property like it was a single path, but it is actually a list of paths. While I was at it, I added the ability to load the gnu.io.rxtx.properties file from the classpath. Just add the properties file to your application's jar and you're good to go. 2. Fixed unsafe code in the registerSpecifiedPorts method. First of all, system properties should NOT be messed with. In addition, the code was not thread-safe - one thread could be changing the system properties while another one is trying to read them - producing unpredictable results. I'm not sure what the project's code formatting rules are. The RxTxCommDriver.java file is indented with spaces and tabs. The method I changed was mostly tabs, so I used those. If anyone could point me to a "Contributors Best Practices" page I would appreciate it! -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_1.patch Type: text/x-diff Size: 5652 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 16:04:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 15:04:47 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <751226.22708.qm@web63107.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patch. A small change to RXTXCommDriver.java: made fields that never change final. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_2.patch Type: text/x-diff Size: 6783 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 17:38:21 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 16:38:21 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <361602.91359.qm@web63106.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. Changed CommPortIdentifier.java: Create a single instance of RXTXCommDriver. This eliminates a lot of unnecessary code. RXTXCommDriver should be a singleton and implement the factory pattern, but that will require updating the JNI interfaces. I will get to that later if these patches make it into the project. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_3.patch Type: text/x-diff Size: 12055 bytes Desc: not available URL: From adrian.crum at yahoo.com Sun Aug 8 18:20:50 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 17:20:50 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: <361602.91359.qm@web63106.mail.re1.yahoo.com> Message-ID: <835338.16379.qm@web63105.mail.re1.yahoo.com> It looks like the patches are getting scrubbed - even though they are text files. -Adrian --- On Sun, 8/8/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 4:38 PM > The attached patch is cumulative - it > includes the previous patches. > > Changed CommPortIdentifier.java: Create a single instance > of RXTXCommDriver. This eliminates a lot of unnecessary > code. > > RXTXCommDriver should be a singleton and implement the > factory pattern, but that will require updating the JNI > interfaces. I will get to that later if these patches make > it into the project. > > -Adrian > > > ? ? ? > -----Inline Attachment Follows----- > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at yahoo.com Sun Aug 8 22:33:41 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:33:41 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <448906.78624.qm@web63105.mail.re1.yahoo.com> The attached patch is cumulative - it includes the previous patches. A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. 2. Synchronized access to the listener Vector in CommPortIdentifier. 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. This will be my last patch for now. If these changes make it into the project, then I will submit more. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_4.patch Type: text/x-diff Size: 27220 bytes Desc: not available URL: From george.dma at gmail.com Sun Aug 8 22:37:46 2010 From: george.dma at gmail.com (George H) Date: Mon, 9 Aug 2010 07:37:46 +0300 Subject: [Rxtx] Patch In-Reply-To: <835338.16379.qm@web63105.mail.re1.yahoo.com> References: <361602.91359.qm@web63106.mail.re1.yahoo.com> <835338.16379.qm@web63105.mail.re1.yahoo.com> Message-ID: Thanks for sending those patches on the list. I hope one of the rxtx project leaders will look into the bug tracker. Actually I wonder if they thought of hosting the project on sourceforge, a lot of the trackers, forums and repos will be provided. -- George H george.dma at gmail.com On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum wrote: > It looks like the patches are getting scrubbed - even though they are text files. > > -Adrian > > --- On Sun, 8/8/10, Adrian Crum wrote: > >> From: Adrian Crum >> Subject: [Rxtx] Patch >> To: rxtx at qbang.org >> Date: Sunday, August 8, 2010, 4:38 PM >> The attached patch is cumulative - it >> includes the previous patches. >> >> Changed CommPortIdentifier.java: Create a single instance >> of RXTXCommDriver. This eliminates a lot of unnecessary >> code. >> >> RXTXCommDriver should be a singleton and implement the >> factory pattern, but that will require updating the JNI >> interfaces. I will get to that later if these patches make >> it into the project. >> >> -Adrian >> >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> 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 adrian.crum at yahoo.com Sun Aug 8 22:59:40 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 8 Aug 2010 21:59:40 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <779723.93075.qm@web63105.mail.re1.yahoo.com> Trent is looking into it. He thought it might be Yahoo's spam filters blocking the delivery of my password. So I tried two other email hosts and those didn't come through either. I agree Sourceforge would be a better host for this project. -Adrian --- On Sun, 8/8/10, George H wrote: > From: George H > Subject: Re: [Rxtx] Patch > To: rxtx at qbang.org > Date: Sunday, August 8, 2010, 9:37 PM > Thanks for sending those patches on > the list. > I hope one of the rxtx project leaders will look into the > bug tracker. > > Actually I wonder if they thought of hosting the project > on > sourceforge, a lot of the trackers, forums and repos will > be provided. > -- > George H > george.dma at gmail.com > > > > On Mon, Aug 9, 2010 at 3:20 AM, Adrian Crum > wrote: > > It looks like the patches are getting scrubbed - even > though they are text files. > > > > -Adrian > > > > --- On Sun, 8/8/10, Adrian Crum > wrote: > > > >> From: Adrian Crum > >> Subject: [Rxtx] Patch > >> To: rxtx at qbang.org > >> Date: Sunday, August 8, 2010, 4:38 PM > >> The attached patch is cumulative - it > >> includes the previous patches. > >> > >> Changed CommPortIdentifier.java: Create a single > instance > >> of RXTXCommDriver. This eliminates a lot of > unnecessary > >> code. > >> > >> RXTXCommDriver should be a singleton and implement > the > >> factory pattern, but that will require updating > the JNI > >> interfaces. I will get to that later if these > patches make > >> it into the project. > >> > >> -Adrian > >> > >> > >> > >> -----Inline Attachment Follows----- > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 07:10:51 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 07:10:51 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: <448906.78624.qm@web63105.mail.re1.yahoo.com> References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Sun, 8 Aug 2010, Adrian Crum wrote: > The attached patch is cumulative - it includes the previous patches. > > A number of changes to make RXTXCommDriver and CommPortIdentifier thread-safe: > > 1. Converted CommPortIdentifier linked list to a HashMap and moved it to RXTXCommDriver, put RXTXCommDriver in control of the Map and have CommPortIdentifier delegate method calls to RXTXCommDriver. > > There was a flaw in the design. One thread could be traversing the linked list while another thread is modifying it - causing unpredictable results or NPEs. > > 2. Synchronized access to the listener Vector in CommPortIdentifier. > > 3. Fixed the open method in CommPortIdentifier. Even though the method included synchronized blocks, it was not thread-safe - another thread could change the object's state in the gaps between the synchronized blocks. > > This will be my last patch for now. If these changes make it into the > project, then I will submit more. > Thanks Adrian, I'll be reviewing these and running a test suite on the changes this week. I'll let you know if I find anything. -- Trent Jarvi tjarvi at qbang.org From ron at ronsgallery.com Mon Aug 9 08:31:05 2010 From: ron at ronsgallery.com (Ron Olson) Date: Mon, 09 Aug 2010 10:31:05 -0400 Subject: [Rxtx] Read with 0 timeout doesn't follow spec (Bug 148) Message-ID: <4C601129.8000501@ronsgallery.com> Since this forum appears to be getting more attention for bug reporting than the bug reporting tool, I'm posting a recent bug here (#148), hoping a fix will get folded into the core build. Bug 148 was summarized as "/Read with 0 timeout doesn't follow spec/". Here's the bug description, as originally reported, followed by the fix I'm currently using. It's relative to rxtx-2.2pre2 (i.e. not the CVS latest). It's intended to be as risk-free as possible, while solving the immediately problem. However, I believe a better change would be *always* check for available bytes before giving up with a timeout, rather than just doing so on the first iteration. Ron _Bug 148 Description:_ /The rxtx read() service for a serial port mishandles a timeout value of 0, according to my reading of the java comm spec. I'm basing this on tests I've run, and also on reading the rxtx code (SerialImp.c), version rxtx2.2pre2. According to the Java Comm spec: "Enabling the Timeout OR Threshold with a value a zero is a special case. This causes the underlying driver to poll for incoming data instead of being event driven." I interpret this to mean that if bytes are available, the read() service with timeout 0ms should retrieve and return the bytes, rather than letting a timer immediately fire and return no bytes. One simple test is this: 1) Send bytes from another device into the port. 2) Issue available() call, to verify bytes are ready for retrieval. 3) Issue read() call with timeout of 0ms. No bytes are returned. Reviewing the code shows the problem. If the timeout has expired, which of course it has if the value is 0, the read() method immediately returns with no bytes, not implementing the required 'poll'. The fix is simple - just a slight reordering of the code - and I've done that and verified the bytes are now returned with the 0 timeout value. IMO the spec wording is clear enough that this a bug, not an implementer's choice. For what it's worth, the Sun implementation adheres to the spec, returning available bytes when the timeout is 0./ /_ _/_Bug 148 Fix (in SerialImp.c)_: 3074,3075c3074,3076 < if (timeout >= 0) { < now = GetTickCount(); --- > // check for timeout, but only after first time through > now = GetTickCount(); > if (count>1 && timeout >= 0) { -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Aug 9 09:11:29 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 9 Aug 2010 17:11:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5DC372.4070304@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> <4C5DC372.4070304@tu-bs.de> Message-ID: 2010/8/7 Nejd Zrelli > Hi Mariusz, > > Funny methode with the generation of exception with data. :-) > I have found your message in the archive of 2009 November but unfortunately > I can't read the java source code. > > Funny or not, but works very fast. ;)). I have developed it first for transfering data through JNI from Windows to Java. I was very begginer this time :). here is this code attached. Regards Mariusz > Regards, > Nejd > > Am 06.08.2010 19:26, schrieb M.Dec-GMail: > > Hi Nejd >> I have had same challenge - data handling as fast as possible. >> Events was mysterious and slow so I did it using separate Java thread for >> continious reading serial buffer from Java side. >> If data comes in, I am parsing it and if data is ok I am generating Java >> exception with data to main application. >> I have published an example in 2009 November in the thread RXTX close() >> problem solved. >> Analyse it and if you will have more question, ask. >> Regards >> Mariusz >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialCommMd.zip Type: application/zip Size: 2419 bytes Desc: not available URL: From adrian.crum at yahoo.com Mon Aug 9 12:27:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 11:27:47 -0700 (PDT) Subject: [Rxtx] Problem compiling C code Message-ID: <285015.25751.qm@web63105.mail.re1.yahoo.com> Using the current repo, I'm trying to compile the C code on Windows XP. The various make files reference two files that don't exist: config.h and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those files? Are the make files current? -Adrian From adrian.crum at yahoo.com Mon Aug 9 13:36:36 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 12:36:36 -0700 (PDT) Subject: [Rxtx] Solved: Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: <901157.89799.qm@web63103.mail.re1.yahoo.com> I figured out the problem. C code is compiling fine. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Problem compiling C code > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 11:27 AM > Using the current repo, I'm trying to > compile the C code on Windows XP. The various make files > reference two files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Aug 9 14:26:47 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 9 Aug 2010 14:26:47 -0600 (MDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: <285015.25751.qm@web63105.mail.re1.yahoo.com> References: <285015.25751.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Adrian Crum wrote: > Using the current repo, I'm trying to compile the C code on Windows XP. > The various make files reference two files that don't exist: config.h > and gnu_io_CommPortIdentifier.h. Does anyone know where I can find those > files? Are the make files current? > Hi Adrian, I see you figured it out. Those makefiles are not fault tolerant. There are more than one windows makefile. They are not very robust but should be functional with some path edits. gnu_io_*.h are generated from the class files with javah. config.h is usually generated by a Makefile. config.h: Makefile echo "#define HAVE_FCNTL_H 1" > config.h echo "#define HAVE_SIGNAL_H 1" >> config.h echo "#define HAVE_SYS_FCNTL_H 1" >> config.h echo "#define HAVE_SYS_FILE_H 1" >> config.h echo "#undef HAVE_SYS_SIGNAL_H" >> config.h echo "#undef HAVE_TERMIOS_H" >> config.h $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 9 15:16:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 14:16:09 -0700 (PDT) Subject: [Rxtx] Problem compiling C code In-Reply-To: Message-ID: <912456.55808.qm@web63107.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Adrian Crum wrote: > > > Using the current repo, I'm trying to compile the C > code on Windows XP. The various make files reference two > files that don't exist: config.h and > gnu_io_CommPortIdentifier.h. Does anyone know where I can > find those files? Are the make files current? > > > > Hi Adrian, > > I see you figured it out.? Those makefiles are not > fault tolerant. > > There are more than one windows makefile.? They are > not very robust but should be functional with some path > edits. > > gnu_io_*.h are generated from the class files with javah. > config.h is usually generated by a Makefile. > > config.h: Makefile > ? ? ? ? echo "#define HAVE_FCNTL_H 1" > > config.h > ? ? ? ? echo "#define HAVE_SIGNAL_H 1" > >> config.h > ? ? ? ? echo "#define HAVE_SYS_FCNTL_H > 1" >> config.h > ? ? ? ? echo "#define HAVE_SYS_FILE_H > 1" >> config.h > ? ? ? ? echo "#undef HAVE_SYS_SIGNAL_H" > >> config.h > ? ? ? ? echo "#undef HAVE_TERMIOS_H" > >> config.h > > > $(JAVAH) $(CLASSPATH) -jni gnu.io.RXTXPort > gnu.io.CommPortIdentifier gnu.io.LPRPort gnu.io.RXTXVersion Thanks Trent! I'm using MSVC ver 6. I created a new project and included the necessary files - bypassing the RxTx make files. I ran into one compilation problem, which I have a patch for. -Adrian From adrian.crum at yahoo.com Mon Aug 9 17:00:54 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 16:00:54 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <243564.99422.qm@web63101.mail.re1.yahoo.com> I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? -Adrian From johnny.luong at trustcommerce.com Mon Aug 9 17:36:51 2010 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 09 Aug 2010 16:36:51 -0700 Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> References: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <4C609113.1090105@trustcommerce.com> Adrian Crum wrote: > I tried out the patch in Bug 144 - JRE crashing when a serial connection is broken. The patch doesn't fix the problem for me. I'm using Windows XP and an ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a good approach. But I see comments in the code that say overlapped I/O was needed to avoid system hangs. Could someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > Hi Adrian, I think the reason overlapped IO is used is to allow progression on the device when a read/write occurs on the serial port. I think the issue lies in that somewhat imprecise mapping between the USB device (along with many other scenarios like redirecting a network port) and the behavior of a physical serial port. So sometimes you would get strange errors and because its not caught / handled correctly, it would crash. Hope that helps, Johnny From adrian.crum at yahoo.com Mon Aug 9 23:18:35 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 9 Aug 2010 22:18:35 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: <243564.99422.qm@web63101.mail.re1.yahoo.com> Message-ID: <320987.85671.qm@web63102.mail.re1.yahoo.com> I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > ? ? ? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From mariusz.dec at gmail.com Tue Aug 10 00:02:01 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 10 Aug 2010 08:02:01 +0200 Subject: [Rxtx] Bug 144 References: <320987.85671.qm@web63102.mail.re1.yahoo.com> Message-ID: Hi Adrian, I have eliminated JRE crashes using a lot of exceptions traps in Java code only(!) on 2.2 pre dated on end of 2009 r. It was quite simple. Only side effect was system messages from JNI part on console. Using this technique I can reconnect serial in application from Java side, without closing application. Here is a part of code, working, direct from app, I hope you will find most important elements. Somebody says me that catching exceptions inside catch isn;'t good idea, but for me works a long time in Java from 6_x_16. Regards Mariusz Dec //****************************************************************************** /** * This thread serves serial port reading and parses incoming data.
* If keyboard's data block is completed, exeception is thrown and keyboard number is transferred to Exception routine in KHSerialBufException. * If Host Firmware Version is detected, HOST Version string is prepared.
* Data blocks are:
* Block identifier(0xC0), keyboard number(nn), keyboard modifiers state(mm) and Keystroke (ss): 0xC0nnmmss
* Block identifier(0xE0), keyboard number(nn), keyboard battery voltage (vvvv) : 0xE0nnvvvv
* Keyboard battery voltage is stored to table and may be displayed as shown in dialogs.DlgKbdPanel.java
*/ public static class serialReader implements Runnable { private static InputStream in; public serialReader ( InputStream inStrm ) { synchronized(stopReadMutex) {stopRead = false;} serialReader.in = inStrm; } //&&&&&&&&&&&&&&&&& public void run () { byte[] buffer = new byte[bufMax+1]; byte[] sbuff = new byte[bufMax+1]; int len = -1; int ix = 0; curPackIdx =0; try { while ( ( len = serialReader.in.read(buffer)) > -1 ) { if (stopRead) { break; } if (len>0){ for (ix=0; ix3){ for (int lix =0; lix<4 ; lix++) {sbuff[lineLen]=curPack[lix]; lineLen++; } if (curPack[0]== CMD_F0) { kbdHostVersion = new String(curPack,1,3); kbdHostVersion = "V" + kbdHostVersion; } else { kbNbr = curPack[1]; if (kbNbr > kbdsNbr) kbNbr=0; kbdConnected[kbNbr] =1; } if (curPack[0]== CMD_E0) { kbdBattery[kbNbr]= arr2intBE(curPack,2); } curPackIdx=0; } } } int oix =0; if (lineLen >=4) { while (oix < lineLen) { if (sbuff[oix]== CMD_C0){ kbNbr = sbuff[oix+1]; kbdConnected[kbNbr] =1; if (kbNbr>0) { byte bb = 0; bb = (byte) kbdHostOffset; kbNbr = kbNbr + bb; } kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 2]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; kbBufTab[kbNbr][kbRxIdxTab[kbNbr]] = sbuff[oix + 3]; kbRxIdxTab[kbNbr]++; if (kbdhost.KHConnector.kbRxIdxTab[kbNbr] >= bufMax) kbdhost.KHConnector.kbRxIdxTab[kbNbr]=0; try{throw new kbdhost.KHSerialBufException(kbNbr);} catch (Exception e){} } oix = oix+4; } lineLen = 0; } } } } catch ( IOException e ) { if (errPrint) System.out.println("Exception in serialReader: "+e.toString()); e.printStackTrace(); try{ serialReader.in.close(); serialPort.close(); Thread.currentThread().interrupt(); }catch (Exception ex) { if (errPrint) System.out.println("Exception closing port in serialReader: " + ex.toString()); } } } } ----- Original Message ----- From: "Adrian Crum" To: Sent: Tuesday, August 10, 2010 7:18 AM Subject: Re: [Rxtx] Bug 144 I lied. The Bug 144 patch works - disconnecting a serial cable no longer crashes the JRE. But the rest of RxTx doesn't recover very well. I will be working on making the code a little more fault tolerant. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 4:00 PM > I tried out the patch in Bug 144 - > JRE crashing when a serial connection is broken. The patch > doesn't fix the problem for me. I'm using Windows XP and an > ethernet device that is mapped to a COM port. > > Looking at the C code, I'm thinking overlapped I/O is not a > good approach. But I see comments in the code that say > overlapped I/O was needed to avoid system hangs. Could > someone get me up to speed on what those issues were? > > -Adrian > > > > > _______________________________________________ > 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 Bruce.Griffith at se-eng.com Tue Aug 10 03:33:59 2010 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 10 Aug 2010 03:33:59 -0600 Subject: [Rxtx] Windows Makefile Message-ID: <001601cb386f$29ae1170$7d0a3450$@Griffith@se-eng.com> How are production releases of the Windows DLLs for Eclipse build? I want to build in the 2.2 fixes and get all of the appropriate DLLs. Thanks . -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Tue Aug 10 03:48:12 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 10 Aug 2010 10:48:12 +0100 Subject: [Rxtx] Example for wiki - but the wiki is down! Message-ID: Hi, I have an example I'd like to add to the wiki but I find today that the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php "Server not found" "Firefox can't find the server at rxtx.qbang.org". Regards, Michael Erskine. From tjarvi at qbang.org Tue Aug 10 13:08:49 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 10 Aug 2010 13:08:49 -0600 (MDT) Subject: [Rxtx] Example for wiki - but the wiki is down! In-Reply-To: References: Message-ID: On Tue, 10 Aug 2010, Michael Erskine wrote: > Hi, > I have an example I'd like to add to the wiki but I find today that > the wiki is down for some reason: http://rxtx.qbang.org/wiki/index.php > "Server not found" "Firefox can't find the server at rxtx.qbang.org". It should be working. I'm accessing it from off site as well. -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Tue Aug 10 14:52:04 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 13:52:04 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <113773.11439.qm@web63107.mail.re1.yahoo.com> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: bug-144.patch Type: text/x-patch Size: 9583 bytes Desc: not available URL: From adrian.crum at yahoo.com Tue Aug 10 15:01:09 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:01:09 -0700 (PDT) Subject: [Rxtx] Fw: Re: Windows Makefile Message-ID: <315584.59137.qm@web63108.mail.re1.yahoo.com> For some reason, my reply didn't make it through on the first try. -Adrian --- On Tue, 8/10/10, Adrian Crum wrote: From: Adrian Crum Subject: Re: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 6:12 AM It appears to me that the project is set up for command line tools. I use Eclipse for the Java side, and Microsoft Visual C for the C side. I created an ant build file to compile the Java code, create the jar, and create the JNI C headers. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: From: Bruce Griffith Subject: [Rxtx] Windows Makefile To: rxtx at rxtx.qbang.org Date: Tuesday, August 10, 2010, 2:33 AM How are production releases of the Windows DLLs for Eclipse build?? I want to build in the 2.2 fixes and get all of the appropriate DLLs. ? Thanks ? -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 15:13:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 14:13:37 -0700 (PDT) Subject: [Rxtx] Patch Message-ID: <753447.32030.qm@web63103.mail.re1.yahoo.com> The attached patch fixes a compile-time error caused by a bad preprocessor directive in ParallelImp.c. -Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: rxtx-devel_5.patch Type: text/x-patch Size: 687 bytes Desc: not available URL: From johnco3 at gmail.com Tue Aug 10 16:00:49 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 18:00:49 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code. By the way well done kick starting the effort to move the code forward. Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 16:36:48 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 15:36:48 -0700 (PDT) Subject: [Rxtx] Bug 144 Message-ID: <553967.45635.qm@web63102.mail.re1.yahoo.com> The patch is for the current repo. The fix isn't finished. Although I was able to get the thread to stop spewing error messages, it ends up leaving the SerialPort instance in a weird state. The main problem is most of the C code assumes there will never be an I/O error, so when one occurs there is no way to handle it. My thinking is we should scrap 2.x and move to 3. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 3:00 PM Adrian, is there any chance you could attach your termios.c & SerialImp.c so I could rebuild with them. I got the following hunk errors when trying to apply the patch to my already patched 2.2 code.? By the way well done kick starting the effort to move the code forward.? Perhaps one of these years we may even go to version 2.2 :) John $ patch --dry-run -i bug-144.patch patching file SerialImp.c Hunk #1 succeeded at 3953 (offset 70 lines). Hunk #2 FAILED at 4005. Hunk #3 succeeded at 4098 (offset 70 lines). Hunk #4 succeeded at 4181 (offset 73 lines). Hunk #5 succeeded at 4222 (offset 73 lines). Hunk #6 succeeded at 4972 (offset 83 lines). 1 out of 6 hunks FAILED -- saving rejects to file SerialImp.c.rej patching file termios.c Hunk #1 succeeded at 1302 (offset 45 lines). Hunk #2 FAILED at 1357. Hunk #3 succeeded at 1374 (offset 45 lines). Hunk #4 succeeded at 1399 (offset 45 lines). Hunk #5 succeeded at 1409 (offset 45 lines). Hunk #6 succeeded at 3162 with fuzz 2 (offset 429 lines). Hunk #7 FAILED at 3205. 2 out of 7 hunks FAILED -- saving rejects to file termios.c.rej On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 20:09:03 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 19:09:03 -0700 (PDT) Subject: [Rxtx] Windows Makefile In-Reply-To: <008901cb38de$df9d6340$9ed829c0$@Griffith@se-eng.com> Message-ID: <33252.64565.qm@web63101.mail.re1.yahoo.com> There are a number of source files that aren't needed. I can't send you the project file - since it contains hard-coded references to folders on my system. But I'm willing to describe how I set up my project. Create a folder called VisualStudio in the main RxTx folder. Inside that folder create two folders: rxtxParallel and rxtxSerial. Create a new project in the rxtxParallel folder. Project type is Win32 Dynamic Link Library. Project name is rxtxParallel. Choose a simple DLL if asked. The stub files (*.cpp and *.h) the wizard creates can be shared by both DLLs, so move those files to the VisualStudio folder, and then update your project to reflect the new file locations. Add the following files to your project: ParallelImp.c, termios.c, ParallelImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The parallel DLL project should be ready to build - give it a try. Create a new project in the rxtxSerial folder. Project type is Win32 Dynamic Link Library. Project name is rxtxSerial. Choose an empty DLL if asked. Update your project to include the stub files created previously. Add the following files to your project: SerialImp.c, termios.c, SerialImp.h, win32termios.h. In project settings, add the Java SDK include files to the include directories in the C++ preprocessor section: path\to\sdk\include, path\to\sdk\include\win32 The serial DLL project should be ready to build - give it a try. -Adrian --- On Tue, 8/10/10, Bruce Griffith wrote: > From: Bruce Griffith > Subject: RE: [Rxtx] Windows Makefile > To: adrian.crum at yahoo.com > Date: Tuesday, August 10, 2010, 3:53 PM > It is, but there are as many > Makefiles for DLLs as there are users, none of > them ?official?.? I?m using Visual Studio 2010 > Express? nmake with the > 2.2pre2 ?Windows.msvc? Makefile.? It doesn?t > compile without fixes, and it > leaves a bunch of source files unused, so I?m wondering > what gives.? Is the > Windows Makefile file obsolete, or is the I2C and RS485 > support incomplete? > > I was kind of hoping that Trent would "sanction" one of the > methods and the > Makefile for building Windows files. > > Can you send me your MSVC project files? > > Thanks, > Bruce Griffith > Sage Electronic Engineering, LLC > 303-532-4778 > > --- On Tue, 8/10/10, Adrian Crum yahoo.com> wrote: > > From: Adrian Crum > Subject: Re: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 6:12 AM > > It appears to me that the project is set up for command > line tools. > > I use Eclipse for the Java side, and Microsoft Visual C for > the C side. I > created an ant build file to compile the Java code, create > the jar, and > create the JNI C headers. > > -Adrian > > --- On Tue, 8/10/10, Bruce Griffith se-eng.com> wrote: > > From: Bruce Griffith > Subject: [Rxtx] Windows Makefile > To: rxtx at rxtx.qbang.org > Date: Tuesday, August 10, 2010, 2:33 AM > > How are production releases of the Windows DLLs for > Eclipse > build?? I want to build in the 2.2 fixes and get all of > the appropriate > DLLs. > > Thanks ? > > > From iqzw2r602 at sneakemail.com Tue Aug 10 21:25:14 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 11 Aug 2010 13:25:14 +1000 Subject: [Rxtx] About JRE crashes Message-ID: <7835-1281497115-502628@sneakemail.com> Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc.), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. My native wrappers look like this (see [1] and [2]): class Unix{ public static native int read(int fd, byte[] buffer); public static int pipe(int[] pipefds); ... } class Windows{ public static native int ReadDirectoryChangesW(...); .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 21:36:11 2010 From: johnco3 at gmail.com (John Coffey) Date: Tue, 10 Aug 2010 23:36:11 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <113773.11439.qm@web63107.mail.re1.yahoo.com> References: <113773.11439.qm@web63107.mail.re1.yahoo.com> Message-ID: Adrian, I built x64 & x32 with all your patches - rxtx-devel_4.patch - rxtx-devel_5.patch - bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: *WARNING: RXTX Version mismatch* * Jar version = RXTX-2.2* * native lib Version = RXTX-2.2pre2* * * I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. Hope this is of some help and I wish it was easier to sort this mess out :) John # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame: # C [rxtxSerial.dll+0x5b4a] # # An error report file with more information is saved as: # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. get_java_var: invalid file descriptor # See problematic frame for where to report the bug. driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 21:53:05 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 20:53:05 -0700 (PDT) Subject: [Rxtx] Bug 144 In-Reply-To: Message-ID: <560303.36226.qm@web63101.mail.re1.yahoo.com> John, The version warning is normal for the repo code. Thanks for giving it a try - your input helps. The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. -Adrian --- On Tue, 8/10/10, John Coffey wrote: From: John Coffey Subject: Re: [Rxtx] Bug 144 To: rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:36 PM Adrian,? I built x64 & x32 with all your patches? - rxtx-devel_4.patch - rxtx-devel_5.patch- bug-144.patch - so far so good, however I'm getting the error when I initialize rxtx: WARNING: ?RXTX Version mismatch ?? ? ? ?Jar version = RXTX-2.2?? ? ? ?native lib Version = RXTX-2.2pre2 I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). ?I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. ? Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch?(im-uart-disconnect-1.patch)?from some other developer in the rxtx forum (sorry, i don't?recall?who deserves the credit for that patch). ?The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. ?Anyways the 2.2 code with these patches seemed to be quite stable. I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following?exception occasionally. ? Hope this is of some help and I wish it was easier to sort this mess out :) John ## A fatal error has been detected by the Java Runtime Environment: ## ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836## JRE version: 6.0_20-b02# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) # Problematic frame:# C ?[rxtxSerial.dll+0x5b4a]## An error report file with more information is saved as:# C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log ## If you would like to submit a bug report, please visit:# ??http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code.get_java_var: invalid file descriptor# See problematic frame for where to report the bug.driver_has_tiocgicount: ioctl failed! On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. -Adrian --- On Mon, 8/9/10, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Monday, August 9, 2010, 10:18 PM > I lied. The Bug 144 patch works - > disconnecting a serial cable no longer crashes the JRE. But > the rest of RxTx doesn't recover very well. I will be > working on making the code a little more fault tolerant. > > -Adrian > > > --- On Mon, 8/9/10, Adrian Crum > wrote: > > > From: Adrian Crum > > Subject: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 4:00 PM > > I tried out the patch in Bug 144 - > > JRE crashing when a serial connection is broken. The > patch > > doesn't fix the problem for me. I'm using Windows XP > and an > > ethernet device that is mapped to a COM port. > > > > Looking at the C code, I'm thinking overlapped I/O is > not a > > good approach. But I see comments in the code that > say > > overlapped I/O was needed to avoid system hangs. > Could > > someone get me up to speed on what those issues were? > > > > -Adrian > > > > > > > > ? ? ? > > _______________________________________________ > > 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 > ? ? ? _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Aug 10 22:50:11 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 10 Aug 2010 21:50:11 -0700 (PDT) Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: <214371.36782.qm@web63105.mail.re1.yahoo.com> --- On Tue, 8/10/10, iqzw2r602 at sneakemail.com wrote: From: iqzw2r602 at sneakemail.com Subject: [Rxtx] About JRE crashes To: Rxtx at qbang.org Date: Tuesday, August 10, 2010, 8:25 PM Hi there, I've contributed native library packaging in 2008 (so that the native libs live inside the JAR file and get unpacked on the fly and won't need manual installing), so I have had a bit of a look at the rxtx codebase (by the way, as far as I'm aware this hasn't made it into CVS yet - or has it?) What struck me about rxtx is that there is a lot of native code, which means there's a lot that can go wrong and crash the JRE - and I don't think there needs to be. I maintain a library for monitoring directories via OS events (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which obviously requires native libraries. The first attempt followed the rxtx model, with a fat native lib that tries do it all. It failed miserably; file watching is quite hard to abstract on that level, especially when you deal with multiple threads, so it crashed a lot. Also debugging it is a pain; without a cross-language debugger you constantly have to attach to debuggers, one for C/C++, one for Java. And it's awefully time consuming too. So I scrapped the whole thing and replaced the fat native lib with tiny wrappers for OS functions like select(), read(), ReadFile(), etc., and wrote platform specific code on top of that in Java. Actually, that was the intent of the original javax.comm specification. It was a very thin Java interface to what should be a very thin native library. This project seems to have drifted from that goal. ?My native wrappers look like this (see [1] and [2]): class Unix{ ??? public static native int read(int fd, byte[] buffer); ??? public static int pipe(int[] pipefds); ??? .... } class Windows{ ??? public static native int ReadDirectoryChangesW(...); ??? .... } Also find code that's using this (and is platform-specific) in [3]. For rxtx, it might not be too difficult to refactor most C code into Java code this way. When I look at SerialImp.c for example: It implements all sort of methods for the RXTXPort class in C; all of this could be written in Java just as well (and with a lot less error handling, because Java does it all implicitely). I reckon you could simply take the bulk of the file, replace the function headers with java-type method headers and leave most of the function bodies as they are (especially the parts that implement complex logic). Calls to operating system functions like select() etc. would then simply be calls to the native static methods in one of the Windows or Unix classes. I was picturing a facade similar to the current RXTXCommDriver, except it would have all native methods in it. Classes would delegate to the facade. That would result in a single JNI C include file, and various platforms could implement that include file. For Windows, that would also mean a single DLL file instead of two. For me this change of architecture completely paid out, and I think it would help RXTX a lot as well. Probably not to be done over night, but this might be something to aim for in rxtx 3.0. This is a small project. It might take as long as a weekend. ;-) So much for my 10 cents, Cheers, Uwe For reference, you might want to have a look at the jpathwatch codebase: [1] Unix.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup [2] Windows.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup [3] WindowsPathWatchService.java: http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Tue Aug 10 23:01:15 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 01:01:15 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: <560303.36226.qm@web63101.mail.re1.yahoo.com> References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Adrian, that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. http://mailman.qbang.org/2009-September/6401378.html Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. John On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try > - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible > pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On *Tue, 8/10/10, John Coffey * wrote: > > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > *WARNING: RXTX Version mismatch* > * Jar version = RXTX-2.2* > * native lib Version = RXTX-2.2pre2* > * > * > I remember this warning from some time ago, it looks like it was never > fixed in the main development branch (which is 2.1.7 right? rather than 2.2. > I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an > enigma to me). I went to RXTX-2.2pre2 when it became available to me as it > supported a much wider set of baud rates for some special hardware where > 2.1.7 used to throw some sort of error. Besides hand coding the termios.c > open code (with a larger input buffer size), I also incorporated a 2.2 > patch (im-uart-disconnect-1.patch) from some other developer in the rxtx > forum (sorry, i don't recall who deserves the credit for that patch). The > patch addressed uart disconnects (which seem similar to the kinds of things > you are trying to address), I don't think the aforementioned patch made its > way into the repository. Anyways the 2.2 code with these patches seemed to > be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting > together against the mainline via a virtual serial port, however I > encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, > pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode > windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum > > wrote: > > Attached is the updated Bug 144 patch. I had to add a way to stop the > monitor thread when an I/O error occurred, otherwise the thread would spew > error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > From: Adrian Crum > > > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > > > wrote: > > > > > From: Adrian Crum > > > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Aug 10 23:17:12 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 08:17:12 +0300 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> Message-ID: Uwe wrote: > > For me this change of architecture completely paid out, and I think it would > help RXTX a lot as well. Probably not to be done over night, but this might be > something to aim for in rxtx 3.0. > > So much for my 10 cents, I agree with that approach [doing as much as possible in Java and as little as practical in C]. I would also suggest that by using JNA we could get rid of the C code altogether, making (no pun intended) building the code a trivial effort. I've used JNA to access 'libusb' with great success, it was easy, fun and almost trivial and worked an all platforms [where libusb is supported] without a problem. my 2 snt worth br Kusti From rbreznak at neuronrobotics.com Wed Aug 11 04:11:40 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 11 Aug 2010 06:11:40 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: References: <7835-1281497115-502628@sneakemail.com> Message-ID: Anything that would make it easier to deploy and have less reliance on native code would be greatly appreciated from a end-user perspective. Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Wed, Aug 11, 2010 at 1:17 AM, Kustaa Nyholm wrote: > Uwe wrote: > > > > For me this change of architecture completely paid out, and I think it > would > > help RXTX a lot as well. Probably not to be done over night, but this > might be > > something to aim for in rxtx 3.0. > > > > So much for my 10 cents, > > I agree with that approach [doing as much as possible in Java and as little > as practical in C]. > > I would also suggest that by using JNA we could get rid of the C code > altogether, making (no pun intended) building the code a trivial effort. > > I've used JNA to access 'libusb' with great success, it was easy, fun > and almost trivial and worked an all platforms [where libusb is supported] > without a problem. > > my 2 snt worth > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronsgallery.com Wed Aug 11 04:26:21 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 06:26:21 -0400 Subject: [Rxtx] About JRE crashes In-Reply-To: <7835-1281497115-502628@sneakemail.com> References: <7835-1281497115-502628@sneakemail.com> Message-ID: <4C627ACD.808@ronsgallery.com> On the one hand pushing function towards the Java side and away from the C side makes sense. In fact, as a first cut I would typically start a project that way, probably lining the JNI services up with the Linux services, as someone else suggested. But, some of the Java Comm services require multiple Linux calls, and going through JNI for each Linux call has a cost. Implementing carefully selected 'macro level' services at the JNI level could pay off in performance. What's hard to know without actually implementing some of this and taking measurements is whether those performance gains are worth it. And then, there's the question of whether the JNI level for Linux and for Windows should be the same. I haven't looked at that, but it seems at least possible that what's best for one environment isn't best for another. I'm extremely sensitive to performance here, having just spent numerous weeks trying to get an application using RXTX to perform adequately. Ron > Hi there, > > I've contributed native library packaging in 2008 (so that the native > libs live inside the JAR file and get unpacked on the fly and won't > need manual installing), so I have had a bit of a look at the rxtx > codebase (by the way, as far as I'm aware this hasn't made it into CVS > yet - or has it?) > What struck me about rxtx is that there is a lot of native code, which > means there's a lot that can go wrong and crash the JRE - and I don't > think there needs to be. > > I maintain a library for monitoring directories via OS events > (jpathwatch - using ReadDirectoryChangesW(), inotify, etc..), which > obviously requires native libraries. > > The first attempt followed the rxtx model, with a fat native lib that > tries do it all. It failed miserably; file watching is quite hard to > abstract on that level, especially when you deal with multiple > threads, so it crashed a lot. Also debugging it is a pain; without a > cross-language debugger you constantly have to attach to debuggers, > one for C/C++, one for Java. And it's awefully time consuming too. > > So I scrapped the whole thing and replaced the fat native lib with > tiny wrappers for OS functions like select(), read(), ReadFile(), > etc., and wrote platform specific code on top of that in Java. My > native wrappers look like this (see [1] and [2]): > > class Unix{ > public static native int read(int fd, byte[] buffer); > public static int pipe(int[] pipefds); > .... > } > > class Windows{ > public static native int ReadDirectoryChangesW(...); > .... > } > > Also find code that's using this (and is platform-specific) in [3]. > > For rxtx, it might not be too difficult to refactor most C code into > Java code this way. When I look at SerialImp.c for example: It > implements all sort of methods for the RXTXPort class in C; all of > this could be written in Java just as well (and with a lot less error > handling, because Java does it all implicitely). > I reckon you could simply take the bulk of the file, replace the > function headers with java-type method headers and leave most of the > function bodies as they are (especially the parts that implement > complex logic). Calls to operating system functions like select() etc. > would then simply be calls to the native static methods in one of the > Windows or Unix classes. > > For me this change of architecture completely paid out, and I think it > would help RXTX a lot as well. Probably not to be done over night, but > this might be something to aim for in rxtx 3.0. > > So much for my 10 cents, > > Cheers, > > Uwe > > > For reference, you might want to have a look at the jpathwatch codebase: > > [1] Unix.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Unix.java?revision=97&view=markup > > [2] Windows.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/Windows.java?revision=84&view=markup > > [3] WindowsPathWatchService.java: > http://jpathwatch.svn.sourceforge.net/viewvc/jpathwatch/trunk/jpathwatch/jpathwatch-java/src/name/pachler/nio/file/impl/WindowsPathWatchService.java?revision=84&view=markup > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:46:56 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:46:56 +0300 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > I'm extremely sensitive to performance here, having just spent numerous weeks > trying to get an application using RXTX to perform adequately. That is interesting, can you elaborate more, one would think that an application using serial communication (at least at traditional baud rates <= 19200 baud) would not be very sensitive to performance. In any case it would br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 04:54:41 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 13:54:41 +0300 Subject: [Rxtx] rxtx performance requirements In-Reply-To: <4C627ACD.808@ronsgallery.com> Message-ID: > What's hard to know without actually implementing > some of this and taking measurements is whether those performance gains are > worth it. That is so true. > > And then, there's the question of whether the JNI level for Linux and for > Windows should be the same. I haven't looked at that, but it seems at least > possible that what's best for one environment isn't best for another. If rxtx code moves towards an (almost) pure Java implementation then naturally the JNI (or in my preference JNA) level is not the same for different platforms as the JNI/JNA would/should directly interface to the platform API which is different for each platform. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 11 05:04:24 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 11 Aug 2010 14:04:24 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: >> I would also suggest that by using JNA we could get rid of the C code >> altogether, making (no pun intended) building the code a trivial effort. > Anything that would make it easier to deploy and have less reliance on native > code would be greatly appreciated from a end-user?perspective.? With JNA all the interface code is pure Java and JNA itself is a single .jar file, so deployment is very simple. No platform specific native libraries, DLLs etc etc. All you need is the jna.jar file in your classpath and that is it. Or package the jna.jar with your Java application code and you have a single cross platform executable solution. For an example on how easy it is to call standard C library printf from Java in Mac OS X / Linux / Windows see: http://en.wikipedia.org/wiki/Java_Native_Access For details see the project home at: https://jna.dev.java.net/ br Kusti From aawolfe at gmail.com Wed Aug 11 05:34:39 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 11 Aug 2010 07:34:39 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C627ACD.808@ronsgallery.com> Message-ID: On Wed, Aug 11, 2010 at 6:46 AM, Kustaa Nyholm wrote: > >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. > > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > I also have a timing sensitive application that took quite some tweaking to have work well. In my case, we are communicating with a 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no UART/buffer of any sort) and managing to do this reliably at 115,200bps. Also with no flow control (there just aren't enough CPU cycles on the target to do any). Timing is as they say "of the essence". The current RXTX libraries do a very nice job on a wide range of platforms. I'm all for an easier end user distribution, as getting the proper native libraries in place is the #1 issue with new installs now, but please be sure consistent performance is maintained if at all possible. > In any case it would > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ron at ronsgallery.com Wed Aug 11 08:16:13 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 10:16:13 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <4C62B0AD.3010208@ronsgallery.com> >> I'm extremely sensitive to performance here, having just spent numerous weeks >> trying to get an application using RXTX to perform adequately. >> > That is interesting, can you elaborate more, one would think that an > application using serial communication (at least at traditional baud rates > <= 19200 baud) would not be very sensitive to performance. > My implementation is of Modbus RTU. That protocol defines an incoming frame as a set of tightly spaced bytes, followed by 3.5 char-times of dead-time. So, a proper implementation must distinguish incoming bytes as either being close together (e.g. within 2ms at 19,200 bps), or not. And, the link rates can be greater than 19,200 bps, making matters worse. Some Modbus RTU implementations (e.g. Jamod) get around this by inspecting incoming bytes at the front of the frame to infer what the frame length must be, and thus they ignore the true frame definition altogether. Unfortunately, my application must eavesdrop on the bus, where other units are doing the sending, and where frames can arrive quickly, one after another. So, we never know what might come next, and the inference-by-content approach doesn't work for many frame types. To add to the problem, we're limited by a *very* slow CPU, running desktop Linux (i.e. not real time), with all the latency problems that entails, not to mention the latency effects of Java garbage collection. And no, I wasn't involved when the platform was defined, and it may yet change. For now, I'm living with occasional misses on correctly identifying frames, and hopefully I won't need to go further. I believe taking this to a 'perfect' implementation that always correctly finds frame boundaries would likely require going inside the kernel and fielding UART interrupts directly, and assembling frames at that level. That's not likely to happen, since I expect it would be a big deal. But, if needed I might go for some improvements with a middle-ground approach, such as looking more closely inside RXTX for possible optimizations that might help my specific Modbus RTU need, or perhaps trying Linux RT to see how much that helps. I'm open to suggestions on this, either through this forum if it's RXTX related, or directly to me if it's not. Ron From msemtd at googlemail.com Wed Aug 11 08:50:21 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Wed, 11 Aug 2010 15:50:21 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C62B0AD.3010208@ronsgallery.com> References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and just knock together a little device that sits outside the PC to convert Modbus RTU to Modbus ASCII. Then the PC software can take its sweet time! Regards, Michael Erskine. From ilkka at myller.com Wed Aug 11 09:05:13 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 18:05:13 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Hi everyone, Actually, as far as I know, the UART Disconnect patch was never committed to CVS. The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. I have not written revised UART disconnect patch to fix this. If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. -- Ilkka John Coffey kirjoitti 11.8.2010 kello 8.01: > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > John, > > The version warning is normal for the repo code. Thanks for giving it a try - your input helps. > > The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. > > > -Adrian > > --- On Tue, 8/10/10, John Coffey wrote: > > From: John Coffey > > Subject: Re: [Rxtx] Bug 144 > To: rxtx at qbang.org > Date: Tuesday, August 10, 2010, 8:36 PM > > > Adrian, > > I built x64 & x32 with all your patches > > - rxtx-devel_4.patch > - rxtx-devel_5.patch > - bug-144.patch > > - so far so good, however I'm getting the error when I initialize rxtx: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2 > native lib Version = RXTX-2.2pre2 > > I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. > > I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. > > Hope this is of some help and I wish it was easier to sort this mess out :) > > John > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 > # > # JRE version: 6.0_20-b02 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5b4a] > # > # An error report file with more information is saved as: > # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > get_java_var: invalid file descriptor > # See problematic frame for where to report the bug. > driver_has_tiocgicount: ioctl failed! > > On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: > Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. > > -Adrian > > --- On Mon, 8/9/10, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [Rxtx] Bug 144 > > To: rxtx at qbang.org > > Date: Monday, August 9, 2010, 10:18 PM > > I lied. The Bug 144 patch works - > > disconnecting a serial cable no longer crashes the JRE. But > > the rest of RxTx doesn't recover very well. I will be > > working on making the code a little more fault tolerant. > > > > -Adrian > > > > > > --- On Mon, 8/9/10, Adrian Crum > > wrote: > > > > > From: Adrian Crum > > > Subject: [Rxtx] Bug 144 > > > To: rxtx at qbang.org > > > Date: Monday, August 9, 2010, 4:00 PM > > > I tried out the patch in Bug 144 - > > > JRE crashing when a serial connection is broken. The > > patch > > > doesn't fix the problem for me. I'm using Windows XP > > and an > > > ethernet device that is mapped to a COM port. > > > > > > Looking at the C code, I'm thinking overlapped I/O is > > not a > > > good approach. But I see comments in the code that > > say > > > overlapped I/O was needed to avoid system hangs. > > Could > > > someone get me up to speed on what those issues were? > > > > > > -Adrian > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From ron at ronsgallery.com Wed Aug 11 10:08:00 2010 From: ron at ronsgallery.com (Ron Olson) Date: Wed, 11 Aug 2010 12:08:00 -0400 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C62CAE0.9020104@ronsgallery.com> On 08/11/2010 10:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! > > Regards, > Michael Erskine. > I agree with that general idea. What's a shame is that the PC board was custom designed for this product, and could have been supplemented with a microcontroller that could handle the protocol with ease, for negligible extra cost. It reminds me of a talk I heard years ago. The big computer makers (IBM, Amdahl, Univac, etc) would go at each other in computer chess contests on a regular basis. While they rolled in their mainframes (figuratively - they were actually remotely connected), Bell Labs showed up with a meager PDP-11. But, Bell had built a hard-wired board that plugged into the PDP-11, and that was really good at the chess look-ahead logic. The mainframes chugged away while the PDP-11 breezed along. You can guess the outcome. The lesson is, you've got to back away and look at the problem with a systems eye. Ron From johnco3 at gmail.com Wed Aug 11 10:26:52 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 11 Aug 2010 12:26:52 -0400 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: Ilkka, I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? John On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed > to CVS. > > The CVS head has seen several commits/changes since the UART disconnect > patch was released. So, in any case, the content of the patch should be > updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API > methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I > completely agree with him. Breaking backwards compatibility is something > that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. > I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of > such concept in design of serial hardware (dating back decades). UARTs where > fixed part of the system and for example posix, win32 API's do not have any > *standardized* hot-plug features or events. Nowadays UARTs are behind > peripheral buses, wired or wireless, physical or virtual, and can be > unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX > library and supporting event features to RXTX Java API. This allows > developer to handle actual serial hardware disconnects (UART, not to confuse > with cable or equipment disconnects) without resorting to unreliable hacks > involving detection of errorneous outputs from streams or detecting stalled > threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > > Adrian, > > that's a good idea - the rxtx code hasn't really moved forward for ages, > incidentally, I found the source description for the im-uart-disconnect > patch. > http://mailman.qbang.org/2009-September/6401378.html > Now that I recall, I think that was applied to the mainline code. The > patch (available in the archives is 77k) and requires the use of a > separate PortAlreadyClosedException. I have found this code to be very > stable for the past year or so and I've deployed it on linux, win32, win64 & > partially macosx. > John > > On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: > >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a >> try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in >> digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On *Tue, 8/10/10, John Coffey * wrote: >> >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> *WARNING: RXTX Version mismatch* >> * Jar version = RXTX-2.2* >> * native lib Version = RXTX-2.2pre2* >> * >> * >> I remember this warning from some time ago, it looks like it was never >> fixed in the main development branch (which is 2.1.7 right? rather than 2.2. >> I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an >> enigma to me). I went to RXTX-2.2pre2 when it became available to me as it >> supported a much wider set of baud rates for some special hardware where >> 2.1.7 used to throw some sort of error. Besides hand coding the termios.c >> open code (with a larger input buffer size), I also incorporated a 2.2 >> patch (im-uart-disconnect-1.patch) from some other developer in the rxtx >> forum (sorry, i don't recall who deserves the credit for that patch). The >> patch addressed uart disconnects (which seem similar to the kinds of things >> you are trying to address), I don't think the aforementioned patch made its >> way into the repository. Anyways the 2.2 code with these patches seemed to >> be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been >> putting together against the mainline via a virtual serial port, however I >> encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out >> :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, >> pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode >> windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum >> > wrote: >> >> Attached is the updated Bug 144 patch. I had to add a way to stop the >> monitor thread when an I/O error occurred, otherwise the thread would spew >> error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum > >> wrote: >> >> > From: Adrian Crum >> > >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > >> > wrote: >> > >> > > From: Adrian Crum >> > >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Aug 11 10:41:51 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 11 Aug 2010 09:41:51 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <429545.62556.qm@web63108.mail.re1.yahoo.com> --- On Mon, 8/9/10, Trent Jarvi wrote: > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > The attached patch is cumulative - it includes the > previous patches. > > > > A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > > > > 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > > > > There was a flaw in the design. One thread could be > traversing the linked list while another thread is modifying > it - causing unpredictable results or NPEs. > > > > 2. Synchronized access to the listener Vector in > CommPortIdentifier. > > > > 3. Fixed the open method in CommPortIdentifier. Even > though the method included synchronized blocks, it was not > thread-safe - another thread could change the object's state > in the gaps between the synchronized blocks. > > > > This will be my last patch for now. If these changes > make it into the > > project, then I will submit more. > > > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the > changes this week. > I'll let you know if I find anything. Trent, Just apply the first patch. After spending more time with the code trying to fix things, I came to the conclusion it would be simpler/easier to rewrite it. I will get back to you later with a RxTx version 3 proposal. -Adrian From ilkka at myller.com Wed Aug 11 10:58:10 2010 From: ilkka at myller.com (Ilkka Myller) Date: Wed, 11 Aug 2010 19:58:10 +0300 Subject: [Rxtx] Bug 144 In-Reply-To: References: <560303.36226.qm@web63101.mail.re1.yahoo.com> Message-ID: If Adrians work is committed, I'd prefer to write UART Disconnect patch on top of that. And btw. Adrian, great stuff. Thank you :) -- I John Coffey kirjoitti 11.8.2010 kello 19.26: > Ilkka, > > I would definitely be interested as I've been using the one you put together for some time without issues. Would you be considering a patch on top of the work Adrian Crumb has been working on? > > John > > On Wed, Aug 11, 2010 at 11:05 AM, Ilkka Myller wrote: > Hi everyone, > > Actually, as far as I know, the UART Disconnect patch was never committed to CVS. > > The CVS head has seen several commits/changes since the UART disconnect patch was released. So, in any case, the content of the patch should be updated to match current CVS code before considering it for inclusion. > > Also, the original patch I provided included some changes to RXTX Java API methods that were part of original JavaComm method specs. > Trent pointed that out that those changes are not desirable and I completely agree with him. Breaking backwards compatibility is something that should not be done lightly. > I have not written revised UART disconnect patch to fix this. > > If there is interest in including this feature to RXTX, please let me know. I'll create updated and less invasive version of the patch for your review. > > As a reminder: The rationale for "UART disconnect" feature is the lack of such concept in design of serial hardware (dating back decades). UARTs where fixed part of the system and for example posix, win32 API's do not have any *standardized* hot-plug features or events. Nowadays UARTs are behind peripheral buses, wired or wireless, physical or virtual, and can be unplugged from the system at any time. > > UART disconnect patch added UART presence monitoring to the native RXTX library and supporting event features to RXTX Java API. This allows developer to handle actual serial hardware disconnects (UART, not to confuse with cable or equipment disconnects) without resorting to unreliable hacks involving detection of errorneous outputs from streams or detecting stalled threads etc. > > > -- > Ilkka > > > John Coffey kirjoitti 11.8.2010 kello 8.01: > >> Adrian, >> >> that's a good idea - the rxtx code hasn't really moved forward for ages, incidentally, I found the source description for the im-uart-disconnect patch. >> http://mailman.qbang.org/2009-September/6401378.html >> Now that I recall, I think that was applied to the mainline code. The patch (available in the archives is 77k) and requires the use of a separate PortAlreadyClosedException. I have found this code to be very stable for the past year or so and I've deployed it on linux, win32, win64 & partially macosx. >> John >> >> On Tue, Aug 10, 2010 at 11:53 PM, Adrian Crum wrote: >> John, >> >> The version warning is normal for the repo code. Thanks for giving it a try - your input helps. >> >> The thread-safe code is not finished. I'm trying to submit it in digestible pieces because I know a complete rewrite would not be considered. >> >> >> -Adrian >> >> --- On Tue, 8/10/10, John Coffey wrote: >> >> From: John Coffey >> >> Subject: Re: [Rxtx] Bug 144 >> To: rxtx at qbang.org >> Date: Tuesday, August 10, 2010, 8:36 PM >> >> >> Adrian, >> >> I built x64 & x32 with all your patches >> >> - rxtx-devel_4.patch >> - rxtx-devel_5.patch >> - bug-144.patch >> >> - so far so good, however I'm getting the error when I initialize rxtx: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2 >> native lib Version = RXTX-2.2pre2 >> >> I remember this warning from some time ago, it looks like it was never fixed in the main development branch (which is 2.1.7 right? rather than 2.2. I have no idea where the 2.2 code has gone - the 2.1 vs 2.2 branches are an enigma to me). I went to RXTX-2.2pre2 when it became available to me as it supported a much wider set of baud rates for some special hardware where 2.1.7 used to throw some sort of error. Besides hand coding the termios.c open code (with a larger input buffer size), I also incorporated a 2.2 patch (im-uart-disconnect-1.patch) from some other developer in the rxtx forum (sorry, i don't recall who deserves the credit for that patch). The patch addressed uart disconnects (which seem similar to the kinds of things you are trying to address), I don't think the aforementioned patch made its way into the repository. Anyways the 2.2 code with these patches seemed to be quite stable. >> >> I thought I'd give the latest/greatest set of patches you have been putting together against the mainline via a virtual serial port, however I encountered the following exception occasionally. >> >> Hope this is of some help and I wish it was easier to sort this mess out :) >> >> John >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fef20d5b4a, pid=4720, tid=3836 >> # >> # JRE version: 6.0_20-b02 >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode windows-amd64 ) >> # Problematic frame: >> # C [rxtxSerial.dll+0x5b4a] >> # >> # An error report file with more information is saved as: >> # C:\Users\jcoffey\main\javacode\panels\PanelMonitor\hs_err_pid4720.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> get_java_var: invalid file descriptor >> # See problematic frame for where to report the bug. >> driver_has_tiocgicount: ioctl failed! >> >> On Tue, Aug 10, 2010 at 4:52 PM, Adrian Crum wrote: >> Attached is the updated Bug 144 patch. I had to add a way to stop the monitor thread when an I/O error occurred, otherwise the thread would spew error messages until to whole process was shut down. >> >> -Adrian >> >> --- On Mon, 8/9/10, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [Rxtx] Bug 144 >> > To: rxtx at qbang.org >> > Date: Monday, August 9, 2010, 10:18 PM >> > I lied. The Bug 144 patch works - >> > disconnecting a serial cable no longer crashes the JRE. But >> > the rest of RxTx doesn't recover very well. I will be >> > working on making the code a little more fault tolerant. >> > >> > -Adrian >> > >> > >> > --- On Mon, 8/9/10, Adrian Crum >> > wrote: >> > >> > > From: Adrian Crum >> > > Subject: [Rxtx] Bug 144 >> > > To: rxtx at qbang.org >> > > Date: Monday, August 9, 2010, 4:00 PM >> > > I tried out the patch in Bug 144 - >> > > JRE crashing when a serial connection is broken. The >> > patch >> > > doesn't fix the problem for me. I'm using Windows XP >> > and an >> > > ethernet device that is mapped to a COM port. >> > > >> > > Looking at the C code, I'm thinking overlapped I/O is >> > not a >> > > good approach. But I see comments in the code that >> > say >> > > overlapped I/O was needed to avoid system hangs. >> > Could >> > > someone get me up to speed on what those issues were? >> > > >> > > -Adrian >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> -----Inline Attachment Follows----- >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3677 bytes Desc: not available URL: From jredman at ergotech.com Wed Aug 11 16:23:58 2010 From: jredman at ergotech.com (Jim Redman) Date: Wed, 11 Aug 2010 16:23:58 -0600 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: References: <4C62B0AD.3010208@ronsgallery.com> Message-ID: <4C6322FE.9070003@ergotech.com> On 08/11/2010 08:50 AM, Michael Erskine wrote: > Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and > just knock together a little device that sits outside the PC to > convert Modbus RTU to Modbus ASCII. Then the PC software can take its > sweet time! Did I miss an e-mail that detailed a specific performance problem with RXTX? I would agree that an excessive number of calls to native code _might_ create a performance problem, however moving more native code to Java would encourage more code optimizations and probably improved the stability of the whole library. I think that I'm not alone in not wanting to dig into native code, not least because I have to dig up a whole different development system to do this - heck, for some of the code I even have to reboot into Windows!! I suspect that a significant number of people on the list are running Modbus RTU from a standard computer without any problem. We've never seen a real problem with it and RXTX and we've run it on a huge range of embedded systems and desktops, including some system that would now be considered very slow (233MHz Pentium). In principle, there is a fast timing requirement in Modbus RTU, but in practice no device (that I've every met - and that's quite a few) times out that quickly. We've even run the Siemens PPI protocol on the old 233MHz board without a problem and that has much closer timing requirements than Modbus. Now many embedded boards are in the 400+MHz range (I have a phone with a 400MHz ARM), so I would not expect a problem with these "slower" protocols. There are some much faster 115K+ protocols that might be more sensitive to performance. One thing I've never managed to do reliably with RXTX is switch the direction of a 2-wire RS485 port, but since most hardware performs that change automatically this is somewhat irrelevant. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From iqzw2r602 at sneakemail.com Wed Aug 11 17:02:03 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Thu, 12 Aug 2010 09:02:03 +1000 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: <8697-1281567724-79145@sneakemail.com> I have had a quick look at JNA, and it does look like a nice solution for calling native code. However, if you want to minimize call overhead, then it looks like a hand-crafted JNI library is better, especially if you have only a few OS function wrappers to implement. And you can slightly alter the interface for some functions if need be, because you can control it (for instance, you won't need to pass in ints for length of arrays to some functions, because the java array already carries its length) jpathwatch's native libraries only have a handful of functions, and probably half of them might be useful to rxtx as well, so rxtx could probably just borrow the code for them. And adding new ones is pretty simple too. I don't know about the performance requirements of these serial devices, but I couldn't imagine that the few native calls required to read a byte buffer from a file descriptor would create a performance bottle neck. And if one is really identified, you can implement that particular function natively if need be. Cheers, Uwe On Thu, Aug 12, 2010 at 8:23 AM, Jim Redman jredman-at-ergotech.com | rxtx.org mailing list/Example Allow| wrote: > > > On 08/11/2010 08:50 AM, Michael Erskine wrote: > >> Personally, I'd forget using a PC (with a non-RTOS) for Modbus RTU and >> just knock together a little device that sits outside the PC to >> convert Modbus RTU to Modbus ASCII. Then the PC software can take its >> sweet time! >> > > Did I miss an e-mail that detailed a specific performance problem with > RXTX? I would agree that an excessive number of calls to native code > _might_ create a performance problem, however moving more native code to > Java would encourage more code optimizations and probably improved the > stability of the whole library. I think that I'm not alone in not wanting > to dig into native code, not least because I have to dig up a whole > different development system to do this - heck, for some of the code I even > have to reboot into Windows!! > > I suspect that a significant number of people on the list are running > Modbus RTU from a standard computer without any problem. We've never seen a > real problem with it and RXTX and we've run it on a huge range of embedded > systems and desktops, including some system that would now be considered > very slow (233MHz Pentium). > > In principle, there is a fast timing requirement in Modbus RTU, but in > practice no device (that I've every met - and that's quite a few) times out > that quickly. > > We've even run the Siemens PPI protocol on the old 233MHz board without a > problem and that has much closer timing requirements than Modbus. > > Now many embedded boards are in the 400+MHz range (I have a phone with a > 400MHz ARM), so I would not expect a problem with these "slower" protocols. > There are some much faster 115K+ protocols that might be more sensitive to > performance. > > One thing I've never managed to do reliably with RXTX is switch the > direction of a 2-wire RS485 port, but since most hardware performs that > change automatically this is somewhat irrelevant. > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Aug 12 02:30:16 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 09:30:16 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <4C6322FE.9070003@ergotech.com> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> Message-ID: On 11 August 2010 23:23, Jim Redman wrote: > Did I miss an e-mail that detailed a specific performance problem with RXTX? > Jim Hi Jim, Perhaps you missed this email - it's not a specific performance problem with RXTX, rather a specific performance problem with a system that is using RXTX (but still, for the user, a problem)... > I also have a timing sensitive application that took quite some > tweaking to have work well. In my case, we are communicating with a > 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no > UART/buffer of any sort) and managing to do this reliably at > 115,200bps. Also with no flow control (there just aren't enough CPU > cycles on the target to do any). Timing is as they say "of the > essence". The current RXTX libraries do a very nice job on a wide > range of platforms. Hope that clears up any doubt. Regards, Michael Erskine. From mariusz.dec at gmail.com Thu Aug 12 03:33:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 12 Aug 2010 11:33:22 +0200 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) References: <4C62B0AD.3010208@ronsgallery.com><4C6322FE.9070003@ergotech.com> Message-ID: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Hi all, I am looking on this thread from couple of days and I would like to point on few things. 1. Most functions(methods) of the RXTX is very close to JNI and overhead here isn't big. 2. Because of the nature of the Events/Messages in operating systems, service of the events\messages may be slower or faster and it depends of general system busy. There are messages in queue and wait for theirs order of service, queue may be longer or shorter. BTW: A very big number of the messages/events in each system are messages form .... mice. 3. There are some tricks in VCP USB/RS232 dongles/chipsets. For example: FTDI FT232R has a latency paameter USB->serial which may be changed from 1 to 16 ms and this "detail" changes overall performance many more than looks.... Additionaly - too big latency may come to overflow of the buffers in chip or driver. Of course near overflow buffer should be transferred faster, but what I see, this is not true or not always.... - maybe driver problem. Smallest latency finally helps... Discussion over FT232R were here few months ago and after this discussion I have less problems now - Thank you everybody :) What to do? When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. Because of this observation I have thought what may be faster as a normal message events queue. Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! Basing on this idea I have decide to NOT use serial events. Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Regards Mariusz ----- Original Message ----- From: "Michael Erskine" To: Sent: Thursday, August 12, 2010 10:30 AM Subject: Re: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) > On 11 August 2010 23:23, Jim Redman wrote: >> Did I miss an e-mail that detailed a specific performance problem with RXTX? >> Jim > > Hi Jim, Perhaps you missed this email - it's not a specific > performance problem with RXTX, rather a specific performance problem > with a system that is using RXTX (but still, for the user, a > problem)... > >> I also have a timing sensitive application that took quite some >> tweaking to have work well. In my case, we are communicating with a >> 30 year old, 1.78Mhz, 8 bit computer that has only a bit banger (no >> UART/buffer of any sort) and managing to do this reliably at >> 115,200bps. Also with no flow control (there just aren't enough CPU >> cycles on the target to do any). Timing is as they say "of the >> essence". The current RXTX libraries do a very nice job on a wide >> range of platforms. > > Hope that clears up any doubt. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From msemtd at googlemail.com Thu Aug 12 04:59:43 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 12 Aug 2010 11:59:43 +0100 Subject: [Rxtx] rxtx performance requirements (was Re: About JRE crashes) In-Reply-To: <5AE49313E6274EA9A4B9E07406EA4886@mdam2> References: <4C62B0AD.3010208@ronsgallery.com> <4C6322FE.9070003@ergotech.com> <5AE49313E6274EA9A4B9E07406EA4886@mdam2> Message-ID: On 12 August 2010 10:33, M.Dec-GM wrote: > When I have started with RXTX almost one year ago, I have discovered very soon that events are VEEERY slow. > Because of this observation I have thought what may be faster as a normal message events queue. > Solution was very simple - Exceptions as an "emergency" actions of the systems should be faster!!! > Basing on this idea I have decide to NOT use serial events. > Instead of events I am reading continously serial buffer (separate Java thread of course), parse input data inside this thread and after succesfull parsing/sorting data I am generating Exception wich is immediatelly served in main application. > Data from exception is partially transferred as an Exception Message (ASCII) and lets know for main application there somewhere in shared buffer are additional data for app. > This solution works very good and is easy to implement - if somebody wolud like look on this code - please let me know. Hi Mariusz, That's a very effective and creative approach. You could consider a technique from the Java concurrency API, such as a LinkedBlockingDeque to share messages with the main application. That is my usual approach -- I will be posting a working example on the wiki when I have time. If you put your code on the wiki also then the users will have more examples to work from. Regards, Michael. From psuhas at gmail.com Thu Aug 12 14:57:52 2010 From: psuhas at gmail.com (Suhas Pharkute) Date: Thu, 12 Aug 2010 14:57:52 -0600 Subject: [Rxtx] Error in Java Message-ID: Hi, I am getting an error when I load an applet in xulrunner app (mozilla) java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: no suitable image found. Did find: /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper When I did my research it shows me that I need to use -d32 option while launching JVM. I am not sure how to do that? Can some one please help. Thank you, Suhas Pharkute (805) 229-1450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 00:37:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:37:39 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >>> I would also suggest that by using JNA we could get rid of the C code >>> altogether, making (no pun intended) building the code a trivial effort. > >> Anything that would make it easier to deploy and have less reliance on native >> code would be greatly appreciated from a end-user?perspective.? > > With JNA all the interface code is pure Java and JNA itself is a single .jar > file, so deployment is very simple. No platform specific native libraries, > DLLs etc etc. All you need is the jna.jar file in your classpath and > that is it. Or package the jna.jar with your Java application code and > you have a single cross platform executable solution. > > For an example on how easy it is to call standard C library printf from Java > in Mac OS X / Linux / Windows see: > > http://en.wikipedia.org/wiki/Java_Native_Access > > For details see the project home at: > > https://jna.dev.java.net/ > > >From the perspective of rxtx this is another possible direction. We don't need to decide if it is _the_ direction. Don't try to load the wagon with developers, show its the way to go. If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. The solution and problems presented by JNA are an interesting area I've been pondering. This falls more along the lines of catering to some platform specific APIs but using as little of them as possible. Catering to platform specific APIs is a net loss in my opinion but maybe it works. It moves the platform independance responsibility to rxtx in the end. I don't see that we have the resources to do this more than once. The original idea for rxtx was to target POSIX not to become POSIX. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Aug 16 00:47:39 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 00:47:39 -0600 (MDT) Subject: [Rxtx] Patch In-Reply-To: References: <448906.78624.qm@web63105.mail.re1.yahoo.com> Message-ID: On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > >> The attached patch is cumulative - it includes the previous patches. >> >> A number of changes to make RXTXCommDriver and CommPortIdentifier >> thread-safe: >> >> 1. Converted CommPortIdentifier linked list to a HashMap and moved it to >> RXTXCommDriver, put RXTXCommDriver in control of the Map and have >> CommPortIdentifier delegate method calls to RXTXCommDriver. >> >> There was a flaw in the design. One thread could be traversing the linked >> list while another thread is modifying it - causing unpredictable results >> or NPEs. >> >> 2. Synchronized access to the listener Vector in CommPortIdentifier. >> >> 3. Fixed the open method in CommPortIdentifier. Even though the method >> included synchronized blocks, it was not thread-safe - another thread could >> change the object's state in the gaps between the synchronized blocks. >> >> This will be my last patch for now. If these changes make it into the >> project, then I will submit more. >> > > Thanks Adrian, > > I'll be reviewing these and running a test suite on the changes this week. > I'll let you know if I find anything. > I'm just following up to let you know this isnt sitting on a dusty shelf. The patches look fine. I have a meeting Tuesday about testing them. There is a possibility to streamline the process on my end so I'm taking the time to do it. Basically, I use rxtx at work as well and have access to a build and test system that covers the main platforms and has tests used since ~2000 for rxtx. I suspect I'll be able to push this through a set of nontrivial tests Wednesday. Maybe we can get some code coverage numbers as a bonus. I'm also looking at making the tests available outside of that harness. Its something I'm in favor of but takes more than a Tuesday meeting :) -- Trent Jarvi tjarvi at qbang.org From adrian.crum at yahoo.com Mon Aug 16 08:32:25 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 07:32:25 -0700 (PDT) Subject: [Rxtx] Patch In-Reply-To: Message-ID: <54491.35492.qm@web63107.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Mon, 9 Aug 2010, Trent Jarvi wrote: > > > > > > > On Sun, 8 Aug 2010, Adrian Crum wrote: > > > >> The attached patch is cumulative - it includes the > previous patches. > >> > >> A number of changes to make RXTXCommDriver and > CommPortIdentifier thread-safe: > >> > >> 1. Converted CommPortIdentifier linked list to a > HashMap and moved it to RXTXCommDriver, put RXTXCommDriver > in control of the Map and have CommPortIdentifier delegate > method calls to RXTXCommDriver. > >> > >> There was a flaw in the design. One thread could > be traversing the linked list while another thread is > modifying it - causing unpredictable results or NPEs. > >> > >> 2. Synchronized access to the listener Vector in > CommPortIdentifier. > >> > >> 3. Fixed the open method in CommPortIdentifier. > Even though the method included synchronized blocks, it was > not thread-safe - another thread could change the object's > state in the gaps between the synchronized blocks. > >> > >> This will be my last patch for now. If these > changes make it into the project, then I will submit more. > >> > > > > Thanks Adrian, > > > > I'll be reviewing these and running a test suite on > the changes this week. I'll let you know if I find > anything. > > > > I'm just following up to let you know this isnt sitting on > a dusty shelf. > > The patches look fine.? I have a meeting Tuesday about > testing them. There is a possibility to streamline the > process on my end so I'm taking the time to do it.? > Basically, I use rxtx at work as well and have access to a > build and test system that covers the main platforms and has > tests used since ~2000 for rxtx. > > I suspect I'll be able to push this through a set of > nontrivial tests Wednesday.? Maybe we can get some code > coverage numbers as a bonus. > > I'm also looking at making the tests available outside of > that harness. Its something I'm in favor of but takes more > than a Tuesday meeting :) You must have missed my previous reply. Don't worry about that patch - I have abandoned work on 2.x in favor of a rewrite. I will have a formal V3 proposal ready in about a week. The first patch should get committed though - the one that fixes the properties file issues. In fact, that should be backported to previous versions. -Adrian From adrian.crum at yahoo.com Mon Aug 16 09:08:55 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 08:08:55 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <370266.35744.qm@web63104.mail.re1.yahoo.com> --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user?perspective.? > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction.? We don't > need to decide if it is _the_ direction.? Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory.? If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering.? This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works.? It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian From mariusz.dec at gmail.com Mon Aug 16 11:26:43 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Mon, 16 Aug 2010 19:26:43 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <0C4CFD3F08FE4FCCBD2F297DB56928EB@mdam2> Hi all, A bit Off Topic.... And we are going "back to the future" :))). Java was developed to be platform independent. Very nice idea but.... who knows Operating Systems rules, know what about I am thinking. Finally - everybody is looking how to do Java platform dependend because of ... performance. Surprise or not??? Ok - this example from Wiki gives multiplatform code on the higher level than conditionals in C code and THIS IS a very big step ahead comparing to early 90'ths... I am not Java enemy, but Java's overhead (in fact OS over OS) should be very carefully analysed before use Java on the small/relative slow platforms. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Monday, August 16, 2010 5:08 PM Subject: Re: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) --- On Sun, 8/15/10, Trent Jarvi wrote: > On Wed, 11 Aug 2010, Kustaa Nyholm wrote: > > >>> I would also suggest that by using JNA we > could get rid of the C code > >>> altogether, making (no pun intended) building > the code a trivial effort. > > > >> Anything that would make it easier to deploy and > have less reliance on native > >> code would be greatly appreciated from a > end-user perspective. > > > > With JNA all the interface code is pure Java and JNA > itself is a single .jar > > file, so deployment is very simple. No platform > specific native libraries, > > DLLs etc etc. All you need is the jna.jar file in your > classpath and > > that is it. Or package the jna.jar with your Java > application code and > > you have a single cross platform executable solution. > > > > For an example on how easy it is to call standard C > library printf from Java > > in Mac OS X / Linux / Windows see: > > > > http://en.wikipedia.org/wiki/Java_Native_Access > > > > For details see the project home at: > > > > https://jna.dev.java.net/ > > > > > > From the perspective of rxtx this is another possible > direction. We don't > need to decide if it is _the_ direction. Don't try to > load the wagon with > developers, show its the way to go. > > If you like, I can give cvs access and people can go nuts > in a JNA > directory. If it becomes obvious that we should do > that, great. > > The solution and problems presented by JNA are an > interesting area I've > been pondering. This falls more along the lines of > catering to some > platform specific APIs but using as little of them as > possible. > > Catering to platform specific APIs is a net loss in my > opinion but maybe > it works. It moves the platform independance > responsibility to rxtx in > the end. I don't see that we have the resources to do this > more than > once. I looked at JNA briefly, and I don't like going in that direction. > The original idea for rxtx was to target POSIX not to > become POSIX. Could you elaborate on that more? How does POSIX relate to RXTX? -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From bschlining at gmail.com Mon Aug 16 11:27:32 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 16 Aug 2010 10:27:32 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > > > > > Catering to platform specific APIs is a net loss in my > > opinion but maybe > > it works. It moves the platform independance > > responsibility to rxtx in > > the end. I don't see that we have the resources to do this > > more than > > once. > > I looked at JNA briefly, and I don't like going in that direction. > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Aug 16 16:05:21 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 16 Aug 2010 16:05:21 -0600 (MDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Mon, 16 Aug 2010, Adrian Crum wrote: > --- On Sun, 8/15/10, Trent Jarvi wrote: >> On Wed, 11 Aug 2010, Kustaa Nyholm wrote: >> >>>>> I would also suggest that by using JNA we >> could get rid of the C code >>>>> altogether, making (no pun intended) building >> the code a trivial effort. >>> >>>> Anything that would make it easier to deploy and >> have less reliance on native >>>> code would be greatly appreciated from a >> end-user?perspective.? >>> >>> With JNA all the interface code is pure Java and JNA >> itself is a single .jar >>> file, so deployment is very simple. No platform >> specific native libraries, >>> DLLs etc etc. All you need is the jna.jar file in your >> classpath and >>> that is it. Or package the jna.jar with your Java >> application code and >>> you have a single cross platform executable solution. >>> >>> For an example on how easy it is to call standard C >> library printf from Java >>> in Mac OS X / Linux / Windows see: >>> >>> http://en.wikipedia.org/wiki/Java_Native_Access >>> >>> For details see the project home at: >>> >>> https://jna.dev.java.net/ >>> >>> >> >> From the perspective of rxtx this is another possible >> direction.? We don't >> need to decide if it is _the_ direction.? Don't try to >> load the wagon with >> developers, show its the way to go. >> >> If you like, I can give cvs access and people can go nuts >> in a JNA >> directory.? If it becomes obvious that we should do >> that, great. >> >> The solution and problems presented by JNA are an >> interesting area I've >> been pondering.? This falls more along the lines of >> catering to some >> platform specific APIs but using as little of them as >> possible. >> >> Catering to platform specific APIs is a net loss in my >> opinion but maybe >> it works.? It moves the platform independance >> responsibility to rxtx in >> the end. I don't see that we have the resources to do this >> more than >> once. > > I looked at JNA briefly, and I don't like going in that direction. > >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > The termios (basically all the serial specific stuff) calls are POSIX calls. Right now, the API exists and is supported on windows but not all versions. Microsoft has started including the POSIX layer in their servers, if they do it for all their systems, the funky code in rxtx that provices ioctl/termios/... for windows could go away with a few minor adjustments. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:20:09 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:20:09 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi? Tried to find some documentation or tutorial but couldn't ...so what is the difference / advantage? Does it work on all the platforms where JNA works? br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:30:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:30:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: > > I looked at JNA briefly, and I don't like going in that direction. > Ok, but it would be helpful if you elaborated a bit... the point about JNA is ease of deployment and development. In my experience the simple task of compiling C as you need to do with JNI can be a major headache especially for user and in open source projects users are often told to 'grab the latest CVS and compile' which more often than not does not work out of the box. >> The original idea for rxtx was to target POSIX not to >> become POSIX. > > Could you elaborate on that more? How does POSIX relate to RXTX? > I too did not get what this means...how accessing the serial port from Java with a few JNA calls would make rxtx become POSIX. >From the users points of view expectation for rxtx is that it is the replacement for Sun's abandoned javacomm. And the expectation for javacomm is that we can access the serial port from Java in a platform independent manner. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 00:43:48 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 09:43:48 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: don't like going in that direction. >> >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their > servers, if they do it for all their systems, the funky code in rxtx > that provices ioctl/termios/... for windows could go away with a few > minor adjustments. > > -- > Trent Jarvi > tjarvi at qbang.org I may have lost the thread a bit but ... maybe that is because I have not looked into the rxtx code. >From above I gather that rxtx is coded so that it works on POSIX and on Windows there is some C code that makes Windows look more or less like POSIX, is this correct? On the face of it, that looks very reasonable. What I was suggesting was to just do the low level access to the OS using JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that can easily be coded in Java. The ease of development, maintenance and deployment is so much better with JNA than with JNI. All the developer has to do is to include the jna.jar in the classpath and create a few classes/interfaces in Java. No C compiler and the associated pain in sight. The same goes for the users of rxtx (if it takes the JNA route) and even for the users of those applications using rxtx. br Kusti From adrian.crum at yahoo.com Tue Aug 17 00:56:47 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Mon, 16 Aug 2010 23:56:47 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <333325.87714.qm@web63106.mail.re1.yahoo.com> --- On Mon, 8/16/10, Kustaa Nyholm wrote: > > I looked at JNA briefly, and I don't like going in > that direction. > > > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. I don't see where it makes development or deployment any easier. > In my experience the simple task of compiling C as you need > to do with > JNI can be a major headache especially for user and in open > source > projects users are often told to 'grab the latest CVS and > compile' > which more often than not does not work out of the box. Are you experiencing that headache with this project in particular? I haven't used C in years, and I was able to download the RXTX repo, set up my dev environment and get it to compile within a few hours. > >> The original idea for rxtx was to target POSIX not > to > >> become POSIX. > > > > Could you elaborate on that more? How does POSIX > relate to RXTX? > > > > I too did not get what this means...how accessing the > serial port > from Java with a few JNA calls would make rxtx become > POSIX. What Trent is saying is that RXTX interacts with port hardware using the POSIX API: Java -> JNI -> RXTX native code -> POSIX API -> port hardware -Adrian From george.dma at gmail.com Tue Aug 17 00:59:22 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 09:59:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: On Tue, Aug 17, 2010 at 9:30 AM, Kustaa Nyholm wrote: > >> >> I looked at JNA briefly, and I don't like going in that direction. >> > > Ok, but it would be helpful if you elaborated a bit... > the point about JNA is ease of deployment and development. > In my opinion JNA is just a proxy pattern for gluing the native libs to your java code. Lets say you used JNA with rxtx, you would still needed to code, compile and debug the windows DLL and the linux SO files anyways. In fact this may make development a bit harder. Already in rxtx they have the java side of the code and the C (windows and linux) side of it. And in the middle are the JNI classes that bind things together. When you deploy the jar files, you add them to your class path. JNA may make that part a tad simpler but not by a mile. Using JNA still means you have to work with the native code and they might as well just keep things the way they are. Perhaps organize it more or something. See these references http://today.java.net/article/2009/11/11/simplify-native-code-access-jna https://jna.dev.java.net/ >>> The original idea for rxtx was to target POSIX not to >>> become POSIX. >> >> Could you elaborate on that more? How does POSIX relate to RXTX? >> > > I too did not get what this means...how accessing the serial port > from Java with a few JNA calls would make rxtx become POSIX. > I believe that sounded a bit odd too. rxtx is "targeting" POSIX and Win32 and others anyways. They write the native libs that access the underlying OS to communicate with the serial/parallel ports. So either way with or without JNA you still have to compile,code,debug the native stuff. Providing the native source files is better as you can compile and run it. If you had JNA (I assume) you'd need to compile, package the native lives into some JNA jar package then test it. Trent said > If you like, I can give cvs access and people can go nuts in a JNA directory. If it becomes obvious that we should do that, great. Why not, if it proves to work then great. If not then it doesn't harm anything. -- George H george.dma at gmail.com From mariusz.dec at gmail.com Tue Aug 17 01:25:00 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 09:25:00 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> ----- Original Message ----- From: "George H" To: Sent: Tuesday, August 17, 2010 8:59 AM > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. I agree - 300 percent :). When I am using RXTX in W/M/L environment with JNI, I suppose that peoples like Trent knows many, many more than me about NATIVE W/M/L/.... calls. I don't want to learn about all-platforms-native-calls because rest of the applications need a lot of time as well!!! This is why Java was developed...., I think... WE (programmers) have currently so many things to remember that ready for use JNI like RXTX is very usefull. The important thing is good planning if computing power of the machine with our aplication will be enough for OS over OS (Java over W/M/L/.....). Regards Mariusz From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:34:51 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:34:51 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <333325.87714.qm@web63106.mail.re1.yahoo.com> Message-ID: > > I don't see where it makes development or deployment any easier. > > Are you experiencing that headache with this project in particular? Yes, a few years ago I was able to pull the CVS version and get it to compile on my Mac with just minor adjustments. A year and two Mac's later last year I could not not. I now rely on a precompiled binary and hope it won't break. And no, I have not tried the latest CVS with my latest Mac as I have other things to do than trying to figure out why this or that configure/make/install fails. > I haven't > used C in years, and I was able to download the RXTX repo, set up my dev > environment and get it to compile within a few hours. A few hours?! If it was based on JNA it should be minutes. And that few hours was just for your platform (what ever it is), how about doing this for all the platforms? N times a few hours. > > What Trent is saying is that RXTX interacts with port hardware using the POSIX > API: > > Java -> JNI -> RXTX native code -> POSIX API -> port hardware > > -Adrian > Thanks, got it now. br Kusti From lucio at sulweb.org Tue Aug 17 01:39:25 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 09:39:25 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <201008170939.25390.lucio@sulweb.org> August 17 2010 08:59:22, George H wrote: > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. I believe it is more effectively used to glue your java code to *others* native libs (e.g. host OS native libs). > Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. In fact this may make development a bit harder. The point is, with JNA you don't need to write native code in C anymore, you write it in java and call OS native libs directly from java when needed with runtime lookup of function pointers. This way compilation is easier for users of the rxtx library. I agree debugging and developing rxtx can become a little harder. That said, I've no practical JNA knowledge, so it's more than likely that I miss some important JNA details. August 17 2010 08:43:48, Kustaa Nyholm wrote: > What I was suggesting was to just do the low level access to the OS using > JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that > can easily be coded in Java. Exactly what I mean. August 17 2010 08:56:47, Adrian Crum wrote: > Are you experiencing that headache with this project in particular? I > haven't used C in years, and I was able to download the RXTX repo, set up > my dev environment and get it to compile within a few hours. *A FEW HOURS*? Such a time to setup a build environment is way too much for most rxtx users (non-rxtx-developers), especially since it is a very commonly suggested way to grab the best rxtx code. A library user expects to be able to download it and use it in a few seconds, not hours. For example I need just now to grab the sources only for the crashes problem, and "a few hours", assuming all goes well, seem a bit too much since I don't plan to become a rxtx developer. I think JNA could make this situation better. My 2 cents, Lucio. From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:44:43 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:44:43 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: > > In my opinion JNA is just a proxy pattern for gluing the native libs > to your java code. Lets say you used JNA with rxtx, you would still > needed to code, compile and debug the windows DLL and the linux SO > files anyways. No, not correct. With JNA you don't need a C compiler and you don't need to compile any DLL/SOs. Did you check the example in the wikipedia about calling printf? Absolutely no C-code involved. If and when your favorite OS provides an API you can call from C and link to your application, using JNA you just write a Java interface that conforms to the calling convention and point it to the system library and that is it. > > Already in rxtx they have the java side of the code and the C (windows > and linux) side of it. And in the middle are the JNI classes that bind > things together. I was suggesting, in the context of rewriting things, getting rid of the C side of things. > When you deploy the jar files, you add them to your > class path. JNA may make that part a tad simpler but not by a mile. If you have precompiled (rxtx) libraries available, there is not a big difference, but if you are *developing* a cross platform library there is world of difference in setting up the tool chains for all the platforms and keeping them up-to-date. And like I said, user of open source libraries too often have to compile them. > > Using JNA still means you have to work with the native code and they > might as well just keep things the way they are. Perhaps organize it > more or something. > Like I said, my comments were in the context of rewriting things. If the current code base is just tweaked or improved, naturally there is no point in upsetting things by introducing anything to replace JNI, but if the code is rewritten, then I think it would make sense to seriously consider getting rid of the C-side of things and use JNA. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 01:54:25 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 10:54:25 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <7A2A9A1412C847F3BFE24BCC864E8163@mdam2> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > I agree - 300 percent :). Agree with what? Agree with the wrong conclusion that you still need DLL and/or SO files anyway? Agree with the misguided conclusion that when you don't need to maintain a C compiler tool chain and don't have to debug both C and Java the development is a bit harder? > When I am using RXTX in W/M/L environment with JNI, I suppose that peoples > like Trent knows many, many more than me about NATIVE W/M/L/.... calls. > I don't want to learn about all-platforms-native-calls because rest of the > applications need a lot of time as well!!! The whole point of RXTX is of course that you don't need to know these things. So JNA versus JNI should be mostly irrelevant to you. That is why I don't understand why you care what RXTX does internally and don't understand why you agree 300% with an opinion that dismisses JNA in favor of JNI based on disinformation and out of context. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 02:01:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 11:01:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <201008170939.25390.lucio@sulweb.org> Message-ID: >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. > > I believe it is more effectively used to glue your java code to *others* > native > libs (e.g. host OS native libs). Exactly! > >> Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. In fact this may make development a bit harder. > > The point is, with JNA you don't need to write native code in C anymore, you > write it in java and call OS native libs directly from java when needed with > runtime lookup of function pointers. This way compilation is easier for users > of the rxtx library. I agree debugging and developing rxtx can become a little > harder. That said, I've no practical JNA knowledge, so it's more than likely > that I miss some important JNA details. I have practical knowledge of both JNA and JNI on Linux/Windows/Mac setting using JNA things are so much easier. And when we are talking about calls to native system API, I think debugging is also easier because you don't realy want to step into system calls anyway so all you debugging is on the Java side. There is no C side to debug, hence no need to debug that and as a bonus, provided you pass sensible values to the system calls there is nothing that can crash as Java programs just throw exceptions which are easy to catch, handle and debug. > > August 17 2010 08:43:48, Kustaa Nyholm wrote: >> What I was suggesting was to just do the low level access to the OS using >> JNA. If and when a POSIX emulation (or equivalent mechanism) is needed that >> can easily be coded in Java. > > Exactly what I mean. We are so much on the same page with this! > > August 17 2010 08:56:47, Adrian Crum wrote: >> Are you experiencing that headache with this project in particular? I >> haven't used C in years, and I was able to download the RXTX repo, set up >> my dev environment and get it to compile within a few hours. > > *A FEW HOURS*? Such a time to setup a build environment is way too much for > most rxtx users (non-rxtx-developers), especially since it is a very commonly > suggested way to grab the best rxtx code. A library user expects to be able to > download it and use it in a few seconds, not hours. For example I need just > now to grab the sources only for the crashes problem, and "a few hours", > assuming all goes well, seem a bit too much since I don't plan to become a > rxtx developer. > Could not agree with you more. > I think JNA could make this situation better. I'm sure it would. br Kusti From george.dma at gmail.com Tue Aug 17 02:20:13 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 11:20:13 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: On Tue, Aug 17, 2010 at 10:44 AM, Kustaa Nyholm wrote: > >> >> In my opinion JNA is just a proxy pattern for gluing the native libs >> to your java code. Lets say you used JNA with rxtx, you would still >> needed to code, compile and debug the windows DLL and the linux SO >> files anyways. > > No, not correct. With JNA you don't need a C compiler and you don't need > to compile any DLL/SOs. > > Did you check the example in the wikipedia about calling printf? > > Absolutely no C-code involved. > > If and when your favorite OS provides an API you can call from C and > link to your application, using JNA you just write a Java interface > that conforms to the calling convention and point it to the system > library and that is it. > I have seen the JNA project and I do agree that it creates the interface for you for calling native libraries. It works great if you are just looking to call a method from a native API. I've done this before using JNI and in most cases I've seen using JNA for me would be good. But the problem I see is when I look at the rxtx C source code. I see a lot more than that, there is a quite a bulk of work that is being done. I was seeing using JNA as the abstraction layer between the rxtx java code and the rxtx native code. To which if that was the case then JNA would be a bit useless. I guess I fell into that trap by not explaining too much. So for that I do apologize. However when you mention a complete re-write, this is where things get interesting. This is also where I agree with Trent on making a JNA directory and letting devs go wild and see if this works. I assume they'd have to use JNA to create the access to the native libs. Then just test it to see if everything works. Then I'd assume they'd have to scan the current native code and see what extra calculations and algorithms are being done and apply them in the java code. This part I guess would be time consuming, so it will take effort and time to migrate fully with JNA. I am not the lead of the project and I believe creating a JNA dir for research, dev and testing is a good idea. It helps current rxtx devs to carry on and new devs to re-write portions of the project to use JNA. Then it depends on the project lead as to how the project will evolve. Effectively I would like to hear more technical details from lead devs on this issue, perhaps they can write out the pros and cons on the development side and on the deployment side. This is why I am not really against but not really for JNA. I am for people testing it out, definitely. I am also for keeping what currently works. From mariusz.dec at gmail.com Tue Aug 17 02:31:04 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 17 Aug 2010 10:31:04 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) References: Message-ID: <8129C8E0DD78429D8E8350B8E5474DC7@mdam2> ----- Original Message ----- From: "Kustaa Nyholm" >>> files anyways. In fact this may make development a bit harder. >> >> I agree - 300 percent :). > > Agree with what? Take it easy Kusti :). I was thinking that this is harder because of looking for native calls structure. For example - I know where and how to look for Windows data about it, but I don't know today where to look for it in Linux/Macintosh. I know google, but what for loosing time if I don't think I will be native-programmer in L/M/... > > > The whole point of RXTX is of course that you don't need to know these > things. So JNA versus JNI should be mostly irrelevant to you. > > That is why I don't understand why you care what RXTX does internally and > don't understand why you agree 300% with an opinion that dismisses JNA in > favor of JNI based on disinformation and out of context. > > br Kusti > Ok, in wide context general change of RXTX to JNA looks not bad, if SOMEBOEDY will do it and test it. But if RXTX (as is today) works ....? In our country peoples saying: - Better is the enemy of the good.... When I was writing this post, George H has wriiten about time needed for Java, if Java will do some things as RXTX-C part. So I do not need to rewrite nothing about this very important point :). Regards Mariusz > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From iqzw2r602 at sneakemail.com Tue Aug 17 02:55:24 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 18:55:24 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> Message-ID: <4850-1282035324-678892@sneakemail.com> > > The termios (basically all the serial specific stuff) calls are POSIX > calls. Right now, the API exists and is supported on windows but not all > versions. Microsoft has started including the POSIX layer in their servers, > if they do it for all their systems, the funky code in rxtx that provices > ioctl/termios/... for windows could go away with a few minor adjustments. > That sounds like an appealing option for a rxtx 2.3; reducing complexity is always good for code that should live long. I wonder if that's the way to go for 3.0 though. From first hand experience, the slim direct OS wrapper approach (to have native Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much easier to debug and maintain, because you will not have to debug native code any more. And you could convert the C that calls read() etc. to Java in a snap that way (the Java code will be almost exactly the same with these wrappers!) The solution on Windows can be to either 1) convert your win32 termios wrappers to Java as well, and make Java-converted SerialImp.c code call them. The Java termios can then call win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). 2) Have separate java implementations for a POSIX serial port and a Windows serial port, both in Java, that access the OS via the mentioned slim wrappers. That's the approach that I used for jpathwatch, which has worked very well for me. Option 1) is probably the least work, option 2) the more sustainable and likely to perform better. You can actually do them both in order, because you can later migrate from 1) to 2). And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; they're stable and tested, and exist for Unix and Windows. All that needs to be done is to follow the pattern and add the OS functions you're missing, which I'm happy to assist with. Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Aug 17 03:15:34 2010 From: george.dma at gmail.com (George H) Date: Tue, 17 Aug 2010 12:15:34 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically all the serial specific stuff) calls are POSIX >> calls.. ?Right now, the API exists and is supported on windows but not all >> versions. ?Microsoft has started including the POSIX layer in their servers, >> if they do it for all their systems, the funky code in rxtx that provices >> ioctl/termios/... for windows could go away with a few minor adjustments. > > That sounds like an appealing option for a rxtx 2.3; reducing complexity is > always good for code that should live long. > > I wonder if that's the way to go for 3.0 though. From first hand experience, > the slim direct OS wrapper approach (to have native Unix.read(), > Unix.select(), Unix.open(), etc. java methods) is much easier to debug and > maintain, because you will not have to debug native code any more. And you > could convert the C that calls read() etc. to Java in a snap that way (the > Java code will be almost exactly the same with these wrappers!) > > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then call > win32 function wrappers (Windows.CreateFile(), Windows.ReadFile(), ...). > 2) Have separate java implementations for a POSIX serial port and a Windows > serial port, both in Java, that access the OS via the mentioned slim > wrappers. That's the approach that I used for jpathwatch, which has worked > very well for me. > > Option 1) is probably the least work, option 2) the more sustainable and > likely to perform better. You can actually do them both in order, because > you can later migrate from 1) to 2). > > And I also repeat my offer: Use jpathwatch's slim native wrappers for RXTX; > they're stable and tested, and exist for Unix and Windows. All that needs to > be done is to follow the pattern and add the OS functions you're missing, > which I'm happy to assist with. > > Cheers, > > Uwe > Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Tue Aug 17 06:14:42 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 17 Aug 2010 22:14:42 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <16747-1282047283-672654@sneakemail.com> People post problems on the forums mainly, but youre right, its time to take the bug tracker online. So I just did. If you are look for past issues, look on the forums. Cheers, Uwe On 17/08/2010 7:23 PM, "George H george.dma-at-gmail.com |rxtx.org mailing list/Example Allow|" wrote: On Tue, Aug 17, 2010 at 11:55 AM, wrote: > >> >> The termios (basically ... Hi, I went to the jpathwatch website and to the sourceforge project site. I can't seem to find where you can post bugs or any of the trackers that sourceforge provides. -- George H george.dma at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qban... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyon at docjava.com Tue Aug 17 06:28:29 2010 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 17 Aug 2010 08:28:29 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: Hi All, Has anyone tried using JNA to gain access to web cams? Thanks! - Doug P.S. Quicktime for Java could do this, but Apple killed it. From Kustaa.Nyholm at planmeca.com Tue Aug 17 06:43:11 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 15:43:11 +0300 Subject: [Rxtx] JNA 4 web cams In-Reply-To: Message-ID: > Has anyone tried using JNA to gain access to web cams? Not a web cam but one of these: http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 took me about half an hour to convert the C-headers to a JNA interface and it worked no problem. br Kusti From Steffen.DETTMER at ingenico.com Tue Aug 17 08:09:44 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:09:44 +0200 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: <20100817140944.GA6209@elberon.bln.de.ingenico.com> (OT) * Trent Jarvi wrote on Thu, Aug 05, 2010 at 14:40 -0600: > Some people like it > http://www.metasystema.net/essays/reply-to.html > Some people don't > http://www.unicom.com/pw/reply-to-harmful.html I think both articles are at least around ten years old and I'm afraid the situation still is unchanged, unfortunately. MUAs with proper support of list reply functions, as far as I know, still are rather an exception than the rule - especially webmailers won't offer such a functionality and may not even support any kind of Plug-In that could help (as far as I know, which is very limited). I'm almost sure that even on the latest state-of-the-art hyper-pro-gold "iPhone" clone super device it won't work... Web 2.0, Flash and AJAX - but no mailinglists. Years ago I always was strongly against reply-to munging, because it overwrites the Reply-To: which should be in my authority and invites to accidently to reply to the list instead to the author, but nowadays I see so many problems with daily mails (such as that 95% of the people don't quote well but write 95% of the mails to me etc.), that this one doesn't count much any longer :) Sorry, could not resist, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Aug 17 08:18:42 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:18:42 +0200 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <20100817141842.GB6209@elberon.bln.de.ingenico.com> (OT) Hi Adrian, is it intended to mail to the list to all your postings? I pressed `reply' (not `reply to all'), but since reply-to field asks me to reply the list, so I do :) SCNR. * Adrian Crum wrote on Thu, Aug 05, 2010 at 14:31 -0700: > I'm the former. ;-) Replying to this list will be inconvenient > if I have to keep C&P the ml address in the To: field. I am sure you could find a mail client that makes it still inconvenient... (in other words, Yahoo etc. should be bothered to add this reasonable function) Usually the problem is not copying the ML address, because `reply to all' should set/keep it, but to remove the Authors address to avoid that he gets the mail twice. If you do not use `reply to all' but expect that you reply to all, I think then it is an operating error. SCNR. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From damorales at gmail.com Tue Aug 17 08:25:16 2010 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 17 Aug 2010 10:25:16 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: very interesting ... right now i use v4l4j to use web cams in java apps, but only works on Linux (which is not a problem for me xD) Greetings !! 2010/8/17 Kustaa Nyholm > > > Has anyone tried using JNA to gain access to web cams? > > Not a web cam but one of these: > > > http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 > > took me about half an hour to convert the C-headers to a JNA interface and > it worked no problem. > > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Aug 17 08:55:36 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 17 Aug 2010 16:55:36 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <4850-1282035324-678892@sneakemail.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> Message-ID: <20100817145536.GC6209@elberon.bln.de.ingenico.com> Hi, quite an interesting discussion. In short, I think I like the JNI approach as done by rxtx. It uses native code to handle the native platform specifics. It can use defines and whatever is needed to make it work even on un*x systems which may have problems in termios or other implementations. As far as I know, this is common and implementing serial I/O portable and correctly even today still is a major challenge - best done in C (or C++). * iqzw2r602 at sneakemail.com wrote on Tue, Aug 17, 2010 at 18:55 +1000: > > The termios (basically all the serial specific stuff) calls are > > POSIX calls.. Right now, the API exists and is supported on > > windows but not all versions. Microsoft has started including the > > POSIX layer in their servers, if they do it for all their systems, > > the funky code in rxtx that provices ioctl/termios/... for windows > > could go away with a few minor adjustments. So the Windows termios implementation is really usable? We have some C implementations and found it not fully be portable even across different linux versions - I guess, other un*x systems will be even more different... Personally, I think Javas InputStream/OutputStream approach is not suited for communications. A core problem is the missing timeout support (boolean avialable(long timeout)) and that bidirectional I/O might be tricky (to do without multithreading and without polling), because there is not `available_or_ready_to_write'. > That sounds like an appealing option for a rxtx 2.3; reducing > complexity is always good for code that should live long. > I wonder if that's the way to go for 3.0 though. From first hand > experience, the slim direct OS wrapper approach (to have native > Unix.read(), Unix.select(), Unix.open(), etc. java methods) is much > easier to debug and maintain, because you will not have to debug > native code any more. But what for? I understand that when using JNA and handling the platform specifics in Java code, no native lib has to be deployed, which can make deployment easier, ok. But why should it be easier/faster/better to implement low level communications in Java than in C? Looping around read/write controlled by select or termios IMHO should be easier/faster/better in C. (I understand that a Java developer who is using C not very often will disagree, but just because of personal perferences - which do not matter for rxtx users, because it can be considered an implementation detail). A suited JNI API and implementation IMHO is more powerful. The implementation can call select (or epoll or whatever) before each read/write to let it control timeouts, it could implement both intercharacter and total timeout, maybe also a min threshold or whatever and then have a Java implementation to downgrade this to the InputStream / OutputStream (specialized versions, of course, because at least some SerialInputStream.setTimeout() is needed). In future, I think it would be great if the now internal API to the powerful but `lower-level' JNI functionalities could be defined fixed, documented and `exported' to allow specific implementations (I'm not sure, but I assume that for example some PPP/TCP/IP stack could be better implemented on the JNI interface than on the InputStream-style interface, which, as already told, isn't sufficient anyway). For a version 3.0, why not adding new APIs if it is for good reason? The InputStream stuff isn't useable on it's own, applications have to know that in case of serial I/O setTimeout and whatever has to be called, so where is the problem in offering an appropriate interface (similar as the one used) instead of forcing applications to use the InputStream lookalike that behaves (slightly) differently? If an application relies on control signals, for instance, InputStream won't work anyway. And for those who do not have such requirements (may be most of the users) there of course should the InputStream still be present in a version 3.0. > And you could convert the C that calls read() > etc. to Java in a snap that way (the Java code will be almost exactly > the same with these wrappers!) > The solution on Windows can be to either > 1) convert your win32 termios wrappers to Java as well, and make > Java-converted SerialImp.c code call them. The Java termios can then > call win32 function wrappers (Windows.CreateFile(), > Windows.ReadFile(), ...). But then the `portable' Java code has to know all those platform-specifics - beside potential performance issues due to heaps of calls. > 2) Have separate java implementations for a POSIX serial port and a > Windows serial port, both in Java, sounds a bit funny (`having a portable platform-dependent implementation for each platform in the portable platform-indepenent language') :-) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Aug 17 09:17:09 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 17 Aug 2010 08:17:09 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: My use of RXTX is to distribute it with another Java program (JMRI) RXTX is intensely useful _because_ it works on lots and lots of platforms. When that breaks down, as it has occasionally, and RXTX doesn't work on some specific platform, that's a problem. The last three times this happened, I tried to recompile RXTX to fix what appeared to be relatively simple problems with library versions. This was _not_ a success. I certainly understand that RXTX is a volunteer effort, and that the nitty-gritty of cross-platform compilation is not something that people generally do because they love it. But despite a lot of help from some really strong people, I wasn't able to build a version of RXTX that worked on all existing platforms _plus_ the new compilation. We are therefore currently working with three different sets of RXTX libraries, and there's currently a bug open that will probably require a 4th one. The problem is in compiling the C code. Compiling C code for N platforms is inherently difficult to do when you don't have all N platform's build environments available, and a real pain even when you do. If JNA can live up to it's promise of moving that C code over to Java code, then I think it's a major win. At least I'll be able to compile and distribute it! And if it's easier for me to do, I have to believe it'll be easier for the RXTX team to do it, issue new versions, etc. Bob From Kustaa.Nyholm at planmeca.com Tue Aug 17 10:14:38 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 19:14:38 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com>, Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADC@SRVFIHKIEXB01.pmgroup.local> >My use of RXTX is to distribute it with another Java program (JMRI) >RXTX is intensely useful _because_ it works on lots and lots of >platforms. When that breaks down, as it has occasionally, and RXTX > doesn't work on some specific platform, that's a problem. >The last three times this happened, I tried to recompile RXTX to fix >what appeared to be relatively simple problems with library versions. >This was _not_ a success. Hear hear! > The problem is in compiling the C code. Compiling C code for N >platforms is inherently difficult to do when you don't have all N > platform's build environments available, and a real pain even when you > do. Indeed! >If JNA can live up to it's promise of moving that C code over to Java >code, then I think it's a major win. At least I'll be able to compile >and distribute it! And if it's easier for me to do, I have to believe >it'll be easier for the RXTX team to do it, issue new versions, etc. Well put. br Kusti From Kustaa.Nyholm at planmeca.com Tue Aug 17 10:35:22 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 17 Aug 2010 19:35:22 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com>, <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> >In short, I think I like the JNI approach as done by rxtx. It >uses native code to handle the native platform specifics. That by itself has no value, as far as I can see. > It can use defines and whatever is needed to make it work even on un*x > systems which may have problems in termios or other > implementations. Platform specific defines are about the only thing one gains from using using 'native' code. But then again, the preferred distribution for any application, from the end user point of view, are compiled executables, so having platform dependencies handled by compile time decisions is bad. > As far as I know, this is common and > implementing serial I/O portable and correctly even today still > is a major challenge Agree. > - best done in C (or C++). Why? >Personally, I think Javas InputStream/OutputStream approach is >not suited for communications. A core problem is the missing > timeout support (boolean avialable(long timeout)) and that > bidirectional I/O might be tricky (to do without multithreading > and without polling), because there is not > `available_or_ready_to_write'. This is true as far as it goes. However we have timeout in rxtx and javacomm and many of us live with it. In any case the spec for rxtx/javacomm is what it is (ie it uses Streams) so we have to live with that in this context. And this of course has nothing to do with JNA/JNI. Surely we could create a new API that would fix these and other semantic issues with javacomm, and why not. However a lot of people use what we have today and would not like to change their code so any new API would be best created as separate API. >But why should it be easier/faster/better to implement low level >communications in Java than in C? Because you don't need to handle/understand two different language runtimes and don't have to have a C tool chain, which as many have testified here is often a major headache. >Looping around read/write >controlled by select or termios IMHO should be >easier/faster/better in C. (I understand that a Java developer >who is using C not very often will disagree, but just because of >personal perferences - which do not matter for rxtx users, >because it can be considered an implementation detail). On theoretical level it is an implementation level but in practice a lot of user are forced to compile the code and need to get into terms with the hell of getting C code to compile and link. > A suited JNI API and implementation IMHO is more powerful. The > implementation can call select (or epoll or whatever) before each > read/write to let it control timeouts, it could implement both > intercharacter and total timeout, maybe also a min threshold or > whatever and then have a Java implementation to downgrade this to > the InputStream / OutputStream (specialized versions, of course, > because at least some SerialInputStream.setTimeout() is needed). What ever you can do with JNI you can do more easily with JNA. I fail to see what are the advantages of implementing things on C. Performance is the only thing that comes to mind but that is an issue that needs to be considered in actual context with calculations and measurements, not with assumption that doing things on C is faster and therefore better. >In future, I think it would be great if the now internal API to > the powerful but `lower-level' JNI functionalities could be > defined fixed, documented and `exported' to allow specific > implementations (I'm not sure, but I assume that for example some > PPP/TCP/IP stack could be better implemented on the JNI interface > than on the InputStream-style interface, which, as already told, > isn't sufficient anyway). If such a cross platform C library existed it would be great and we would not need rxtx at all (except of course the existing code base) and could call directly that library using JNI or JNA. >For a version 3.0, why not adding new APIs if it is for good > reason? Why not create a new project for that? Let's keep rxtx what it is ie a replacement for javacomm. >But then the `portable' Java code has to know all those >platform-specifics - What is the objection to that? Either the C or Java side needs to do/know this and as demonstrated (IMO) doing it on the Java side has a lot of advantages. >beside potential performance issues due to heaps of calls. This is so loaded with assumptions that I won't bother. >> 2) Have separate java implementations for a POSIX serial port and a >> Windows serial port, both in Java, >sounds a bit funny (`having a portable platform-dependent >implementation for each platform in the portable >platform-indepenent language') :-) Yeah, I see the irony but to me it actually makes a lot of sense. br Kusti From adrian.crum at yahoo.com Tue Aug 17 12:16:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 17 Aug 2010 11:16:00 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> Message-ID: <102598.14191.qm@web63101.mail.re1.yahoo.com> --- On Tue, 8/17/10, Kustaa Nyholm wrote: > What ever you can do with JNI you can do more easily with > JNA. > I fail to see what are the advantages of implementing > things on C. Let's make one thing perfectly clear - using JNA instead of JNI will NOT make things easier. You're simply moving code up the stack from C to Java - but it will still be the same code. Instead of trying to convince everyone how easy JNA is based on a simple printf example in a Wiki - why don't you prove it? Implement RXTX using JNA and make us all believers. Until then, you're just making things up. -Adrian From bschlining at gmail.com Tue Aug 17 12:40:20 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 17 Aug 2010 11:40:20 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: > > > > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi > > Tried to find some documentation or tutorial but couldn't ...so what is the > difference / advantage? > > Does it work on all the platforms where JNA works? > I think JRuby is now using JFFI for native code interaction; so yes it should be very cross-platform. The author of JFFI is a contributor to both JRuby and JNA (See http://www.mail-archive.com/dev at jruby.codehaus.org/msg03607.html) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucio at sulweb.org Tue Aug 17 15:14:43 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 17 Aug 2010 23:14:43 +0200 Subject: [Rxtx] JNA alternative (was: rxtx moving from JNI to JNA (was Re: About JRE crashes)) In-Reply-To: <20100817145536.GC6209@elberon.bln.de.ingenico.com> References: <370266.35744.qm@web63104.mail.re1.yahoo.com> <4850-1282035324-678892@sneakemail.com> <20100817145536.GC6209@elberon.bln.de.ingenico.com> Message-ID: <201008172314.43315.lucio@sulweb.org> August 17 2010 16:55:36, Steffen DETTMER wrote: > just because of > personal perferences - which do not matter for rxtx users, > because it can be considered an implementation detail). I agree that users don't really care about how things work, but only until they are forced to understand them in order to have a patch applied. Personally I like the JNA idea, but there is at least one other less intrusive solution to the problem, that is to stay with JNI and to provide unofficial, unsupported, nightly (or weekly/monthly) cvs snapshot builds that include all the somewhat tested patches so far. That way users can try one of the snapshot builds instead of building from source themselves. What's the meaning of "somewhat tested patches"? Well, maybe any patch downloadable from a "resolved" bug report (but bug 144 is still "NEW" while a patch does exist and seems to work, so we have to decide the exact rules that make patches go into the snapshot build). The resulting build will be unsupported after all, just the same way a compilation done by a casual user is unofficial and unsupported. When the user knows a particurlar patch solves his problems, he can (if he likes) grab cvs sources, apply only that one patch he needs, set up a build environment and compile sources himself: at least the user will know in advance he is not wasting hours of time to apply a possibly useless-for-him patch. Or he can live with the unofficial and unsupported snapshot if he finds it works for him. Let me know what you think about my proposal. Since in the current situation I'm forced to set up a build environment for linux only to test the patch attached to bug 144 on linux, I could provide unofficial and unsupported builds for linux platforms on a regular basis if someone helps me spot the patches and distinguish between the "somewhat tested" ones and the others. From Kustaa.Nyholm at planmeca.com Wed Aug 18 02:52:39 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 11:52:39 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: > Let's make one thing perfectly clear - using JNA instead of JNI will NOT make > things easier. Depends on what 'things' you are talking about and in what context and for who it does not make things easier. But it is difficult to see your point of view ie why would it not be easier if you don't have to deal with two tool chains and languages. > You're simply moving code up the stack from C to Java - but it > will still be the same code. Of course the code is the same, but the practicalities are hugely different. > Instead of trying to convince everyone how easy JNA is based on a simple > printf example in a Wiki - why don't you prove it? > Implement RXTX using JNA and make us all believers. I have no need to convince you or anyone else, I'm happy with rxtx the way it is at the moment. As long as I can get a pre-compiled binary that just works for the platforms that I need it for, it is all that I need. I was talking in the context of someone's suggestion that a re-write is contemplated and was merely suggesting that in that case it might make sense to to get rid of the C stuff and the associated practical problems. > Until then, you're just making things up. I don't think that was a gentlemanly remark worth of a reply. br Kusti From george.dma at gmail.com Wed Aug 18 03:31:44 2010 From: george.dma at gmail.com (George H) Date: Wed, 18 Aug 2010 12:31:44 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: On Wed, Aug 18, 2010 at 11:52 AM, Kustaa Nyholm wrote: > >> Instead of trying to convince everyone how easy JNA is based on a simple >> printf example in a Wiki - why don't you prove it? >> Implement RXTX using JNA and make us all believers. > > I have no need to convince you or anyone else, I'm happy with rxtx the > way it is at the moment. As long as I can get a pre-compiled binary that > just works for the platforms that I need it for, it is all that I need. > > I was talking in the context of someone's suggestion that a re-write is > contemplated and was merely suggesting that in that case it might make > sense to to get rid of the C stuff and the associated practical problems. > Yeah it seems that context got taken out of hand. Adrian Crum was talking about re-write here http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html There is still the part of performance issue mentioned by many. And this one got lost from the thread since the subject changed http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html If you are happy with how RXTX is then continue to be happy, provide input and let developers be open to experimentation. It seems you are pretty adamant about using JNA. It seems to be good for a lot of things but maybe not for RXTX. The only way i can see JNA being used productively in RXTX is to be the proxy pattern between the Java code and the Native rxtx code. From what I read on this list and from looking at the native source code, it is likely that a performance hit will be a big issue if the code is moved up the stack to java. Should some people disagree then they should do a performance test with a test lib where they shifted some of the code up the stack. >> Until then, you're just making things up. > > I don't think that was a gentlemanly remark worth of a reply. > Don't take it personally, we are all computer people, we trust evidence based on experiments and benchmarks more than people's claims. -- George H george.dma at gmail.com From iqzw2r602 at sneakemail.com Wed Aug 18 04:07:10 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 18 Aug 2010 20:07:10 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <102598.14191.qm@web63101.mail.re1.yahoo.com> References: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6ADD@SRVFIHKIEXB01.pmgroup.local> <102598.14191.qm@web63101.mail.re1.yahoo.com> Message-ID: <14743-1282126034-652758@sneakemail.com> The main difference is that your wrapper for, say, select() is generated by JNA and doesnt have to be hand coded in JNI with C/C++. In my mind thats an advantage and in deed does make things easier. But as said, there might be other reasons why not to use it, maybe the wrappers are not as nice? What does JNA do with pointers to structs passed into functions? Do you have to deal with raw memory in Java? (you can avoid both in hand written JNI wrappers). How does it deal with os functions like ReadFile() when doing async I/O where the OS holds on to a buffer after the function returns? I have written quite a fair bit of Jni code lately, and these are the things that can make your life difficult if not handled correctly. But youre right, eventually someone has to go out and try it for rxtx ;-) Uwe On 18/08/2010 4:25 AM, "Adrian Crum adrian.crum-at-yahoo.com |rxtx.orgmailing list/Example Allow|" < drvwbrbtut at sneakemail.com> wrote: --- On Tue, 8/17/10, Kustaa Nyholm wrote: > What ever you can do with J... Let's make one thing perfectly clear - using JNA instead of JNI will NOT make things easier. You're simply moving code up the stack from C to Java - but it will still be the same code. Instead of trying to convince everyone how easy JNA is based on a simple printf example in a Wiki - why don't you prove it? Implement RXTX using JNA and make us all believers. Until then, you're just making things up. -Adrian _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://ma... -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Wed Aug 18 04:07:10 2010 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 18 Aug 2010 20:07:10 +1000 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: References: Message-ID: <14740-1282126020-515157@sneakemail.com> Have a look at jpathwatch, it is exactly implemented like that. The only thing thats different to what's dicussed here is that it's low level OS wrappers are implemented in JNI instead of JNA (with typically 10 lines of C++ code each) But whatever your approach for the wrapper (and I see reasons for and against JNA), it shows how simple it can be to implement platform specific code in java when you only do in native code what you absolutely have to. Cheers, Uwe On 18/08/2010 4:49 AM, "Brian Schlining bschlining-at-gmail.com |rxtx.orgmailing list/Example Allow|" < 5j55m8uw1t at sneakemail.com> wrote: > > > > > Instead of JNA, there's also JFFI, http://github.com/wmeissner/jffi > > Tried to find so... I think JRuby is now using JFFI for native code interaction; so yes it should be very cross-platform. The author of JFFI is a contributor to both JRuby and JNA (See http://www.mail-archive.com/dev at jruby.codehaus.org/msg03607.html) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfarkas at lfarkas.org Wed Aug 18 04:14:15 2010 From: lfarkas at lfarkas.org (Farkas Levente) Date: Wed, 18 Aug 2010 12:14:15 +0200 Subject: [Rxtx] what's the status of these new patches Message-ID: <4C6BB277.1050400@lfarkas.org> hi, i'm just check the cvs server and there is nothing changed on it in the last few months. is the patches recently appear on this list are dropped or use som kind of other version control system or just not yet applied? thanks. regards. -- Levente "Si vis pacem para bellum!" From adrian.crum at yahoo.com Wed Aug 18 07:15:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 06:15:43 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <3522.82736.qm@web63106.mail.re1.yahoo.com> --- On Wed, 8/18/10, George H wrote: > Kustaa Nyholm > > wrote: > > > >> Instead of trying to convince everyone how easy > JNA is based on a simple > >> printf example in a Wiki - why don't you prove > it? > >> Implement RXTX using JNA and make us all > believers. > > > > I have no need to convince you or anyone else, I'm > happy with rxtx the > > way it is at the moment. As long as I can get a > pre-compiled binary that > > just works for the platforms that I need it for, it is > all that I need. > > > > I was talking in the context of someone's suggestion > that a re-write is > > contemplated and was merely suggesting that in that > case it might make > > sense to to get rid of the C stuff and the associated > practical problems. > > > > Yeah it seems that context got taken out of hand. > Adrian Crum was talking about re-write here > http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html > > There is still the part of performance issue mentioned by > many. And > this one got lost from the thread since the subject > changed > http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html Thank you for bringing this back to the original subject. I tried to fix the JRE crash issue, but I gave up because of two main reasons: the C code is unnecessarily complicated, and error return codes are being ignored. The basic problem I ran into is: Java code calls native method A, native method A calls native method B, and native method B calls native method C. Method C encounters an error and returns an error code to method B. Method B ignores the returned error code and returns success to method A. Java code doesn't know there was an error and continues operating like nothing is wrong. I started fixing the existing code so error codes would be propagated back to Java, but then what do I do with the error code when it's time to return to Java? The original javax.comm specification doesn't allow for errors returned from native code. I also ran into places where threads are being started in native code - which is a bad idea because you could lose control over the thread after you return to Java. Then I found thread synchronization problems in the code... So, I decided to rewrite the library. So far I have the Java code rewritten, and I am currently working on the Windows native code. Once I have it all working, I will make a formal proposal for a new version, post the code, and we can take it from there. I believe once the code is simplified, many of the quirky bugs will go away, deploying native code will be easier, and any discussions about switching to JNA will be moot. -Adrian From george.dma at gmail.com Wed Aug 18 07:38:30 2010 From: george.dma at gmail.com (George H) Date: Wed, 18 Aug 2010 16:38:30 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <3522.82736.qm@web63106.mail.re1.yahoo.com> References: <3522.82736.qm@web63106.mail.re1.yahoo.com> Message-ID: On Wed, Aug 18, 2010 at 4:15 PM, Adrian Crum wrote: > --- On Wed, 8/18/10, George H wrote: >> Kustaa Nyholm >> >> wrote: >> > >> >> Instead of trying to convince everyone how easy >> JNA is based on a simple >> >> printf example in a Wiki - why don't you prove >> it? >> >> Implement RXTX using JNA and make us all >> believers. >> > >> > I have no need to convince you or anyone else, I'm >> happy with rxtx the >> > way it is at the moment. As long as I can get a >> pre-compiled binary that >> > just works for the platforms that I need it for, it is >> all that I need. >> > >> > I was talking in the context of someone's suggestion >> that a re-write is >> > contemplated and was merely suggesting that in that >> case it might make >> > sense to to get rid of the C stuff and the associated >> practical problems. >> > >> >> Yeah it seems that context got taken out of hand. >> Adrian Crum was talking about re-write here >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html >> >> There is still the part of performance issue mentioned by >> many. And >> this one got lost from the thread since the subject >> changed >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html > > Thank you for bringing this back to the original subject. > > I tried to fix the JRE crash issue, but I gave up because of two main reasons: the C code is unnecessarily complicated, and error return codes are being ignored. > > The basic problem I ran into is: Java code calls native method A, native method A calls native method B, and native method B calls native method C. Method C encounters an error and returns an error code to method B. Method B ignores the returned error code and returns success to method A. Java code doesn't know there was an error and continues operating like nothing is wrong. > > I started fixing the existing code so error codes would be propagated back to Java, but then what do I do with the error code when it's time to return to Java? The original javax.comm specification doesn't allow for errors returned from native code. > > I also ran into places where threads are being started in native code - which is a bad idea because you could lose control over the thread after you return to Java. Then I found thread synchronization problems in the code... > > So, I decided to rewrite the library. So far I have the Java code rewritten, and I am currently working on the Windows native code. Once I have it all working, I will make a formal proposal for a new version, post the code, and we can take it from there. > > I believe once the code is simplified, many of the quirky bugs will go away, deploying native code will be easier, and any discussions about switching to JNA will be moot. > > -Adrian > I'm glad that you are taking the initiative to fix these problems and we're all happy because it will benefit us, or at least not yet for me since I am a Linux user :) I do take your word for it about re-writing and it seems you have jump-started the process and the other devs are getting their interest back. btw, I don't know about the javax.comm specs but I would certainly want errors to be returned from native code if it was me. Imagine I call a function from a native library and somewhere inside something bad happens that causes my action to yield an undesirable result. I would want to know that. That is to say that if the result is undesirable then I would want to know, if it is some lower error that maybe can be ignored or occurs anyways for some reason but does not affect the result of what I want, perhaps I wouldn't want that error to be propagated back up. It would cause the "I get an error but it worked" response. Propagating errors... like throwing an exception back up to Java or returning a value (ie, -1 or null or false) indicating an error ? This would need a consensus of the you and the main devs. On a side note, I am happy to see activity in this project :) -- George H george.dma at gmail.com From HowardZ at howardz.com Wed Aug 18 08:27:11 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 18 Aug 2010 10:27:11 -0400 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: References: Message-ID: <4C6BEDBF.9040703@howardz.com> Hi, I have been reading the comments about JNA, and it sounds interesting. It looks like - at least on Windows - that all of rxtx can be written in Java with windows calls going directly to JNA to be invoked on Windows. Whether this will really work out for the complex structures passed to some windows calls remains to be seen. The Java code would need to ask the Java RTE which operating system it is running on, and then load appropriate operating system provided dll/so files, and use the appropriate operating system system calls. Sounds like it will eliminate ALL the C-code - not one line of C code will be needed, greatly simplify the rxtx building process. There would be absolutely no need to build any dll nor so file. There would be no need to have available a Windows PC, and Mac, several Linux PCs to build all the dll/so files. (However, one will need these PCs available to thoroughly test that a change - to assure it works on all these platforms.) These are just my thoughts, as I have never used JNA. It sounds desirable. Howard From adrian.crum at yahoo.com Wed Aug 18 09:06:26 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 08:06:26 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <4C6BEDBF.9040703@howardz.com> Message-ID: <819913.60999.qm@web63102.mail.re1.yahoo.com> --- On Wed, 8/18/10, HowardZ at howardz.com wrote: > Hi, > > I have been reading the comments about JNA, and it sounds > interesting. > > It looks like - at least on Windows - that all of rxtx can > be written in Java with windows calls going directly to JNA > to be invoked on Windows.? Whether this will really > work out for the complex structures passed to some windows > calls remains to be seen. > > The Java code would need to ask the Java RTE which > operating system it is running on, and then load appropriate > operating system provided dll/so files, and use the > appropriate operating system system calls. One thing to keep in mind is the RXTX jar file will include code for ALL supported platforms, not just the one you want to run it on. Unless you want to have a separate jar file for each environment - which exchanges one problem for another. Instead of separate native libs for each environment, you now have separate jars for each environment. I don't know how other members of the community feel about library size, but for me I want RXTX to be as small as possible - so I can have more memory for my application. RXTX on JNA will be huge - because all of the C code will be moved to Java. And as far as eliminating the need to have a separate lib in addition to RXTX - don't forget your application will have to include the JNA lib. Again, you have simply exchanged one problem with another. > Sounds like it will eliminate ALL the C-code - not one line > of C code will be needed, greatly simplify the rxtx building > process.? There would be absolutely no need to build > any dll nor so file.? There would be no need to have > available a Windows PC, and Mac, several Linux PCs to build > all the dll/so files. Any problems anyone might be having compiling the native libs is probably due to the somewhat disorganized layout of the project - it's not because the native libs are written in C. Once I got the project's resources figured out, I was able to get the Windows code to compile easily. I would suggest better project layout and better documentation will improve things a lot more than a switch to JNA. -Adrian From adrian.crum at yahoo.com Wed Aug 18 09:14:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 08:14:43 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: Message-ID: <628799.64371.qm@web63107.mail.re1.yahoo.com> --- On Wed, 8/18/10, George H wrote: > Adrian Crum > wrote: > > --- On Wed, 8/18/10, George H > wrote: > >> Kustaa Nyholm > >> > >> wrote: > >> > > >> >> Instead of trying to convince everyone > how easy > >> JNA is based on a simple > >> >> printf example in a Wiki - why don't you > prove > >> it? > >> >> Implement RXTX using JNA and make us all > >> believers. > >> > > >> > I have no need to convince you or anyone > else, I'm > >> happy with rxtx the > >> > way it is at the moment. As long as I can get > a > >> pre-compiled binary that > >> > just works for the platforms that I need it > for, it is > >> all that I need. > >> > > >> > I was talking in the context of someone's > suggestion > >> that a re-write is > >> > contemplated and was merely suggesting that > in that > >> case it might make > >> > sense to to get rid of the C stuff and the > associated > >> practical problems. > >> > > >> > >> Yeah it seems that context got taken out of hand. > >> Adrian Crum was talking about re-write here > >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848586.html > >> > >> There is still the part of performance issue > mentioned by > >> many. And > >> this one got lost from the thread since the > subject > >> changed > >> http://mailman.qbang.org/pipermail/rxtx/2010-August/6848590.html > > > > Thank you for bringing this back to the original > subject. > > > > I tried to fix the JRE crash issue, but I gave up > because of two main reasons: the C code is unnecessarily > complicated, and error return codes are being ignored. > > > > The basic problem I ran into is: Java code calls > native method A, native method A calls native method B, and > native method B calls native method C. Method C encounters > an error and returns an error code to method B. Method B > ignores the returned error code and returns success to > method A. Java code doesn't know there was an error and > continues operating like nothing is wrong. > > > > I started fixing the existing code so error codes > would be propagated back to Java, but then what do I do with > the error code when it's time to return to Java? The > original javax.comm specification doesn't allow for errors > returned from native code. > > > > I also ran into places where threads are being started > in native code - which is a bad idea because you could lose > control over the thread after you return to Java. Then I > found thread synchronization problems in the code... > > > > So, I decided to rewrite the library. So far I have > the Java code rewritten, and I am currently working on the > Windows native code. Once I have it all working, I will make > a formal proposal for a new version, post the code, and we > can take it from there. > > > > I believe once the code is simplified, many of the > quirky bugs will go away, deploying native code will be > easier, and any discussions about switching to JNA will be > moot. > > > > -Adrian > > > > I'm glad that you are taking the initiative to fix these > problems and > we're all happy because it will benefit us, or at least not > yet for me > since I am a Linux user :) > > I do take your word for it about re-writing and it seems > you have > jump-started the process and the other devs are getting > their interest > back. > > btw, I don't know about the javax.comm specs but I would > certainly > want errors to be returned from native code if it was me. > Imagine I > call a function from a native library and somewhere inside > something > bad happens that causes my action to yield an undesirable > result. I > would want to know that. > > That is to say that if the result is undesirable then I > would want to > know, if it is some lower error that maybe can be ignored > or occurs > anyways for some reason but does not affect the result of > what I want, > perhaps I wouldn't want that error to be propagated back > up. It would > cause the "I get an error but it worked" response. > > Propagating errors... like throwing an exception back up to > Java or > returning a value (ie, -1 or null or false) indicating an > error ? The approach I took was to exploit a loophole in the javax.comm API. It states that if any CommPort methods are called when the port is closed, an IllegalStateException should be thrown (a part of the javax.comm API RXTX does not follow btw). So, if any low-level errors occur, an IOException is passed back to the RXTX Java code, and the Java code catches that exception and closes the port. Any future method calls on that port will generate an IllegalStateException - so the application can take steps to recover. -Adrian From Bob_Jacobsen at lbl.gov Wed Aug 18 09:26:12 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 18 Aug 2010 08:26:12 -0700 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <819913.60999.qm@web63102.mail.re1.yahoo.com> References: <819913.60999.qm@web63102.mail.re1.yahoo.com> Message-ID: <4E9DD51E-5E9F-4BE6-AC87-29D619039B3D@lbl.gov> On Aug 18, 2010, at 8:06 AM, Adrian Crum wrote: > I don't know how other members of the community feel about library > size, but for me I want RXTX to be as small as possible - so I can > have more memory for my application. RXTX on JNA will be huge - > because all of the C code will be moved to Java. What platform are you using it on? The classloaders on the ones I'm familiar with only load classes that are referenced. No memory space is used for classes that aren't referenced. It's possible for un- needed references to creep in, but that's rather straightforward to check for and fix. > And as far as eliminating the need to have a separate lib in > addition to RXTX - don't forget your application will have to > include the JNA lib. Again, you have simply exchanged one problem > with another. You underestimate the problem with native libs. With the current RXTX structure, JMRI has to distribute two separate Windows DLLs, and make sure the right one gets used; three different Linux .so's (ditto), and and four different Mac .jnilibs (ditto, and even harder due to version- dependence). The run-time scripting needed for that takes a lot of work to maintain. That's quite different from having one more .jar file to include (or even merge into a common .jar). It might be possible to build a single RXTX distribution that would work, without having to select different native libraries, across 64 vs 32 bit differences, architecture differences, OS version differences, etc, but I certainly haven't been able to do it. > Any problems anyone might be having compiling the native libs is > probably due to the somewhat disorganized layout of the project - > it's not because the native libs are written in C. Once I got the > project's resources figured out, I was able to get the Windows code > to compile easily. I would suggest better project layout and better > documentation will improve things a lot more than a switch to JNA. Did you build for both 32 and 64 bit Windows? Let alone the various Mac and Linux variants? RXTX is valuable _because_ it's cross-platform. That value is lost when an RXTX version doesn't actually work on multiple platforms. Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From john at buglabs.net Wed Aug 18 09:27:55 2010 From: john at buglabs.net (John Connolly) Date: Wed, 18 Aug 2010 11:27:55 -0400 Subject: [Rxtx] JNA 4 web cams In-Reply-To: References: Message-ID: On Tue, Aug 17, 2010 at 8:43 AM, Kustaa Nyholm wrote: > > > Has anyone tried using JNA to gain access to web cams? > > Not a web cam but one of these: > > > http://www.ids-imaging.de/frontend/products.php?interface=USB&family=SE&tp=0 > > took me about half an hour to convert the C-headers to a JNA interface and > it worked no problem. > What C-headers? From what API? Are they specific to that model of camera? I like v4l4j but the GPL licensing is incompatible with other ASL-based licensed software I use. > > > br Kusti > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ______________________ John Connolly Software Developer Bug Labs 598 Broadway, 4th Floor New York, NY 10012-3206 646.723.9258 jconnolly @ irc.freenode.net/#buglabs -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 18 09:29:48 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 18:29:48 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <628799.64371.qm@web63107.mail.re1.yahoo.com> Message-ID: > > The approach I took was to exploit a loophole in the javax.comm API. It states > that if any CommPort methods are called when the port is closed, an > IllegalStateException should be thrown (a part of the javax.comm API RXTX does > not follow btw). So, if any low-level errors occur, an IOException is passed > back to the RXTX Java code, and the Java code catches that exception and > closes the port. Any future method calls on that port will generate an > IllegalStateException - so the application can take steps to recover. > > -Adrian I'm not against this but strictly speaking the javadoc says: "Once the application is done with the port, it must call the close method. Thereafter the application must not call any methods in the port object. Doing so will cause a java.lang.IllegalStateException to be thrown." So this to me implies that 'closed' means that the close-method has been called, not that the port is de-facto closed because of some internal error. However, if the port is de-facto close then it would be logical to throw IllegalStateException, not to mention that it would be useful. So I'm supporting this behavior. br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 18 09:45:38 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 18:45:38 +0300 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <819913.60999.qm@web63102.mail.re1.yahoo.com> Message-ID: > > I don't know how other members of the community feel about library size, but > for me I want RXTX to be as small as possible - so I can have more memory for > my application. RXTX on JNA will be huge - because all of the C code will be > moved to Java. That (calling it huge) is jumping the gun because we do not have a JNA implementation, not even any idea of its size. And the definition of 'huge' depends on individual circumstance. Standard edition JRE was +50MB the last time I checked. jna.jar is 928 kB. > > Any problems anyone might be having compiling the native libs is probably due > to the somewhat disorganized layout of the project - it's not because the > native libs are written in C. Simply not true, a better make/build process would certainly help the C stuff, but even the best organized builds seem to have compile problems. Witness the endless requests for help to build this or that open source project. Writing cross platform C is very, very difficult. For anyone interested I suggest reading the libusb list archives and seeing how much work they had to put in to get it to compile on all their supported platforms. But I'm not saying JNA is panacea, not by a long shot. There are certainly problems (and solutions) associated with the size of OS API structures that depend on the architecture and especially with the constants (#defines) that you pass to the OS. > Once I got the project's resources figured out, > I was able to get the Windows code to compile easily. Good for you. Did you start with a virgin Windows installation with no tools etc installed? > I would suggest better > project layout and better documentation will improve things a lot more than a > switch to JNA. > Sure, better project layout and better documentation can go a long way but without us testing the JNA approach saying it 'will improve things a lot more than JNA ' is just, to quote an earlier entry on this list, 'making things up'. cheers Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 18 09:49:13 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 18:49:13 +0300 Subject: [Rxtx] JNA 4 web cams In-Reply-To: Message-ID: > What C-headers?? From what API?? Are they specific to that model of camera?? I > like v4l4j but the GPL licensing is incompatible with other ASL-based licensed > software I use > > That camera comes with its own API/DLL and has a header file for that. I simply converted this to a JNA class and all was Hunky-dory. Since then I've learned about JNAerator that will do it for me and when I just tested it on termios.h, the conversion was a sub second thing! br Kusti From adrian.crum at yahoo.com Wed Aug 18 10:01:37 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 18 Aug 2010 09:01:37 -0700 (PDT) Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: Message-ID: <221632.76425.qm@web63101.mail.re1.yahoo.com> --- On Wed, 8/18/10, Kustaa Nyholm wrote: > > I would suggest better > > project layout and better documentation will improve > things a lot more than a > > switch to JNA. > > > > Sure, better project layout and better documentation can go > a long way but > without us testing the JNA approach saying it 'will improve > things a lot > more than JNA ' is just, to quote an earlier entry on this > list, 'making > things up'. Touche' ;-) -Adrian From rvraaphorst at gmail.com Wed Aug 18 11:27:05 2010 From: rvraaphorst at gmail.com (Ronald Raaphorst, van) Date: Wed, 18 Aug 2010 19:27:05 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA In-Reply-To: <221632.76425.qm@web63101.mail.re1.yahoo.com> References: <221632.76425.qm@web63101.mail.re1.yahoo.com> Message-ID: <4E4649E7-3C9F-48B3-B640-48E5C85ED5AA@gmail.com> I cant comment on the technical issues but having a single cross platform jar is very easy to distribute with the application and would make it far easier to create a decent install app imho (i am using rxtx for a cross platform app and i already had trouble getting it all to work on my mbp with snow leopard 1.6) I also would very much like a nightly build system with all sorts of tests so we can easily add patches on a regular basis and be sure the whole lib keeps functioning properly It cant be that hard to script a nightly checkout and run all tests? Isnt this what build servers/apps like hudson are made for? Ronald On 18 aug. 2010, at 18:01, Adrian Crum wrote: > --- On Wed, 8/18/10, Kustaa Nyholm wrote: >>> I would suggest better >>> project layout and better documentation will improve >> things a lot more than a >>> switch to JNA. >>> >> >> Sure, better project layout and better documentation can go >> a long way but >> without us testing the JNA approach saying it 'will improve >> things a lot >> more than JNA ' is just, to quote an earlier entry on this >> list, 'making >> things up'. > > Touche' > > ;-) > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Aug 18 11:45:19 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 18 Aug 2010 19:45:19 +0200 Subject: [Rxtx] rxtx moving from JNI to JNA (was Re: About JRE crashes) In-Reply-To: <628799.64371.qm@web63107.mail.re1.yahoo.com> References: <628799.64371.qm@web63107.mail.re1.yahoo.com> Message-ID: Hi, 2010/8/18 Adrian Crum adrian.crum at yahoo.com > > > The approach I took was to exploit a loophole in the javax.comm API. It > states that if any CommPort methods are called when the port is closed, an > IllegalStateException should be thrown (a part of the javax.comm API RXTX > does not follow btw). So, if any low-level errors occur, an IOException is > passed back to the RXTX Java code, and the Java code catches that exception > and closes the port. Any future method calls on that port will generate an > IllegalStateException - so the application can take steps to recover. > > -Adrian > > > But there is very simple solution, which in my opinion is a good programming practice as well. In my software (Java, Windows) EACH call to Comm functions is AFTER checking if port is yet open... Therefore I can easy react on any problem with hardware or software around COM, I am reading here about problems with RXTX, but I have had only one - close problem because of threads sync and not proper RXTX configuration, specific for platform. I have solved it in Java part of the app. USB/VCP dongle diconnecting is secured ONLY on the Java app side (not RXTX) as well, and works. C code stays untouched in W/M/L... Does my VCP drivers are so good or ....? Regards Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Aug 18 11:45:21 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 20:45:21 +0300 Subject: [Rxtx] termios.h defines ... JNA related Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE2@SRVFIHKIEXB01.pmgroup.local> Hi, toying with the JNA approach, one of the issues is how to handle the #defines like B19200 etc etc. It is of course trivial to have them as constants on the Java side, but there are a few details that will affect how this is best approached. Like: On Mac OS X B19200 has the value on 19200 where as on one Linux it has the value of 16. How much the different Linux constants differ or can we assume that across Linux:es they are the same? The size of some fields in 'struct termios' is size_t according to POSIX, which makes them depend on architecture. Handling this is trivial with JNA but what about the values in those fields? Is it conceivable that the values are different depending on architecture (on the same OS)? Like Mac OS X has i386 (32 bit) ppc (32 bit) and x86_64 (64 bit) architecture and I presume the size of for example c_flags in termios struct is different depending on the architecture (maybe it is not?) but what about the values? br Kusti From Kustaa.Nyholm at planmeca.com Wed Aug 18 11:51:43 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 18 Aug 2010 20:51:43 +0300 Subject: [Rxtx] Non standard baudrates...related to JNA Message-ID: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE3@SRVFIHKIEXB01.pmgroup.local> Now, again considering the JNA approach, there is the issue of passing the baudrates from Java to OS. The Java doc for SerialPort.setSerialPortParams says: If the baudrate passed in by the application is unsupported by the driver, the driver will throw an UnsupportedCommOperationException Now, if and when the interface to OS on unix like system would most likely be based on termios.h/POSIX approach, how would this be handled? One scenario is that the code would check if the value passed to setSerialPortParams for baudrate is one of the standard POSIX baudrates and if so use the corresponding Bxxx from termios.h for that platform and if not , just pass the value directly to the OS. This should support both standard and non standard baudrates (at least setting them, querying could be more tricky). For example Mac OS uses the baudrate value directly whereas Linux uses some magic values. What is the rxtx stand on this? br Kusti From tjarvi at qbang.org Wed Aug 18 11:30:19 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Aug 2010 11:30:19 -0600 (MDT) Subject: [Rxtx] Building and Testing In-Reply-To: <4E4649E7-3C9F-48B3-B640-48E5C85ED5AA@gmail.com> References: <221632.76425.qm@web63101.mail.re1.yahoo.com> <4E4649E7-3C9F-48B3-B640-48E5C85ED5AA@gmail.com> Message-ID: On Wed, 18 Aug 2010, Ronald Raaphorst, van wrote: > I cant comment on the technical issues but having a single cross > platform jar is very easy to distribute with the application and would > make it far easier to create a decent install app imho > > (i am using rxtx for a cross platform app and i already had trouble > getting it all to work on my mbp with snow leopard 1.6) > > I also would very much like a nightly build system with all sorts of > tests so we can easily add patches on a regular basis and be sure the > whole lib keeps functioning properly It cant be that hard to script a > nightly checkout and run all tests? Isnt this what build servers/apps > like hudson are made for? > Getting tests going with Serial Loopback connections in automated environments isn't easy from my experience. That said, having tests with RXTX is a great idea. Ideally, people could use it to track the progress of efforts like JNA attempts. It does seem like there should be a better way to get rxtx builds done. The native and java code combination adds many requirements to what a build cluster needs to provide. I have access to a test suite at work that exercises the basics of RXTX which is run before putting the code into CVS. It isn't a simple process and the test suite isn't easily shared at this time. The big drawback is that it communicates over loopback. The settings are always able to communicate leaving little room for negative tests. Earlier I mentioned a meeting was taking place yesterday regarding building and testing. I've worked out how to get builds and tests done in two batch jobs in some clusters at work which will be good for ~weekly checkpoints but it can't be automated at this point for nightly builds. I can at least share those libraries and the results of the tests. Its going to take a couple days to get everything setup in the cluster but thats next on my plate. I encourage people to explore other options as well. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 18 11:40:28 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 18 Aug 2010 11:40:28 -0600 (MDT) Subject: [Rxtx] Non standard baudrates... In-Reply-To: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE3@SRVFIHKIEXB01.pmgroup.local> References: <5D23E5B41156B646B2E1A7C2BBA916F33A370E6AE3@SRVFIHKIEXB01.pmgroup.local> Message-ID: On Wed, 18 Aug 2010, Kustaa Nyholm wrote: > Now, again considering the JNA approach, there is the issue of passing > the baudrates from Java to OS. > > > The Java doc for SerialPort.setSerialPortParams says: > > If the baudrate passed in by the application is unsupported by the > driver, the driver will throw an UnsupportedCommOperationException > > > Now, if and when the interface to OS on unix like system would most likely be based on termios.h/POSIX approach, > how would this be handled? > > One scenario is that the code would check if the value passed to setSerialPortParams for baudrate is one > of the standard POSIX baudrates and if so use the corresponding Bxxx from termios.h for that platform and > if not , just pass the value directly to the OS. This should support both standard and non standard baudrates > (at least setting them, querying could be more tricky). For example Mac OS uses the baudrate value directly > whereas Linux uses some magic values. > > What is the rxtx stand on this? > The initial reason support for nonstandard baudrates was in rxtx is that I didn't know it was not part of POSIX until I looked at BSD/Solaris/.... I think I saw some discussion that POSIX didn't exclude specific baudrates but the magic number implementation wasnt right. The general interpretation was heading down the same direction you mention Mac OS X does. The right thing to do going forward is to satisfy the needs of people that have a requirement for 'nonstandard' baudrates but provide the support in a standard way (look at what has gone on in Mac OS X/Linux since ~2001). -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Aug 18 23:42:07 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 19 Aug 2010 08:42:07 +0300 Subject: [Rxtx] Default port settings. Message-ID: The javadoc for SerialPort.setSerialPortParams says: "DEFAULT: 9600 baud, 8 data bits, 1 stop bit, no parity" but this makes no sense in the context of that method. So how is this spec interpreted or is it ignored? Is this an implication that a SerialPort that has been opened via CommPortIdentifier.open() but for which setSerialPortParams has not been called defaults to these settings? What does rxtx SerialPort do? What about Sun's SerialPort? If the port defaults to anything, then it is of course easier on the SerialPort code because it never has to convert magic internal numbers to javacomm constants. br Kusti From lucio at sulweb.org Wed Aug 4 08:09:27 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Wed, 4 Aug 2010 16:09:27 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? Message-ID: <201008041609.28061.lucio@sulweb.org> Hello *, I'm new to rxtx and I'm trying to use it on Linux. Unfortunately my customer handed me a usbserial device that is a crap: it keeps disconnecting at random, see for example this snippet from dmesg: [ 316.360581] usb 6-2: new full speed USB device using uhci_hcd and address 127 [ 316.566080] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 316.566115] usb 6-2: Detected FT232RL [ 316.566118] usb 6-2: Number of endpoints 2 [ 316.566121] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 316.566124] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 316.566126] usb 6-2: Setting MaxPacketSize 64 [ 316.567106] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 316.605125] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 316.605142] ftdi_sio 6-2:1.0: device disconnected [ 318.716094] usb 6-2: reset full speed USB device using uhci_hcd and address 127 [ 318.882113] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected [ 318.882201] usb 6-2: Detected FT232RL [ 318.882208] usb 6-2: Number of endpoints 2 [ 318.882214] usb 6-2: Endpoint 1 MaxPacketSize 64 [ 318.882219] usb 6-2: Endpoint 2 MaxPacketSize 64 [ 318.882224] usb 6-2: Setting MaxPacketSize 64 [ 318.884205] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0 When the device disconnects, the file /dev/ttyUSB0 disappears (obviously). Now the problem is how rxtx reacts to this event: instead of raising exceptions or returning error codes, it sometimes (quite a rare event actually) makes the whole java application crash (or does it issue a voluntary System.exit()?). When that happens the output from rxtx is: Experimental: JNI_OnLoad called. and sometimes it outputs also: get_java_var: invalid file descriptor Are you aware of any code paths in rxtx that can make the library reach a System.exit()? Or is it possible that the native part of the library makes the whole application crash/exit? Is there anything I can do to spot the problem? Thanks in advance Lucio. From adrian.crum at yahoo.com Thu Aug 5 11:28:06 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:28:06 -0700 (PDT) Subject: [Rxtx] Project Status Message-ID: <903389.18565.qm@web63103.mail.re1.yahoo.com> I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum From tristan.dyer at cgi.com Thu Aug 5 11:39:36 2010 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Thu, 5 Aug 2010 13:39:36 -0400 Subject: [Rxtx] Project Status In-Reply-To: <903389.18565.qm@web63103.mail.re1.yahoo.com> References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> As far as I can tell it is very much alive ;-) The beta process seems to take a while though. In general the community is top-notch at helping out and the stability of the code is superb. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adrian Crum Sent: Thursday, August 05, 2010 2:28 PM To: rxtx at qbang.org Subject: [Rxtx] Project Status I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. So my questions is: What is the status of this project? -Adrian Crum _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Thu Aug 5 11:50:14 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 19:50:14 +0200 Subject: [Rxtx] Project Status References: <903389.18565.qm@web63103.mail.re1.yahoo.com> Message-ID: Hi, Piiiiiiiiiiiiiiiiiiiiiii.... RXTX Status Message: Do_It_Your_Self. Piiiiiiiiiiiiiiiiiiiii EOM Now without jokes - in many cases problems are not big and you may ask here. There is a lot of not well documented configuration tricks. From the other side - a lot of users don't uderstand transmission's problems and have problem at all... This is a major part of the "bugs". I am using very old 2.2pre without problems and I am tracing this list - sometimes I can help. On this mailing list there is a lot of solutions as well. Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:28 PM Subject: [Rxtx] Project Status >I spent the last two weeks evaluating RxTx and fixing a few problems on my local copy. > > I might be wrong, but it seems to me this project has been abandoned. The latest CVS revision is over a year old, and prior to that the revisions are 4 years old. There are a lot of bug reports that have been ignored. The author doesn't respond to emails. > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at yahoo.com Thu Aug 5 11:57:12 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:57:12 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D04C2F776@MTL-MSG-02.cgiclients.com> Message-ID: <82188.38602.qm@web63103.mail.re1.yahoo.com> Thanks Tristan. I can see that ml questions are answered. I can see that there is a pre-release version that has been around for a while. What I *don't* see is bug reports being handled, patches applied to the repository, you know - the kind of things an active project does. Are there any committers involved with the project besides the author? -Adrian --- On Thu, 8/5/10, Dyer, Tristan wrote: > As far as I can tell it is very much > alive ;-) > > The beta process seems to take a while though. > > In general the community is top-notch at helping out and > the stability > of the code is superb. > > Tristan > > -----Original Message----- > From: rxtx-bounces at qbang.org > [mailto:rxtx-bounces at qbang.org] > On Behalf > Of Adrian Crum > Sent: Thursday, August 05, 2010 2:28 PM > To: rxtx at qbang.org > Subject: [Rxtx] Project Status > > I spent the last two weeks evaluating RxTx and fixing a few > problems on > my local copy. > > I might be wrong, but it seems to me this project has been > abandoned. > The latest CVS revision is over a year old, and prior to > that the > revisions are 4 years old. There are a lot of bug reports > that have been > ignored. The author doesn't respond to emails. > > > So my questions is: What is the status of this project? > > -Adrian Crum > > > > ? ? ? > _______________________________________________ > 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 adrian.crum at yahoo.com Thu Aug 5 11:59:20 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 10:59:20 -0700 (PDT) Subject: [Rxtx] Project Status In-Reply-To: Message-ID: <577984.5133.qm@web63104.mail.re1.yahoo.com> Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > >? ? ? > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Aug 5 11:59:40 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 11:59:40 -0600 (MDT) Subject: [Rxtx] Project Status In-Reply-To: <577984.5133.qm@web63104.mail.re1.yahoo.com> References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Thanks Mariusz. > > The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. > > -Adrian > The way to get fixes into RXTX is to post individual code fixes for individual problems to the list for group review. Often when someone talks about their local fixes, they want to dump whitespace changes and everything else along with switching from CVS because.... If you have a clear fix for a clear problem with no side effects, it can get in. The bug reports are not a contract for support in any fashion. They are to help people identify known issues and potential issues they want to work on. -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Aug 5 12:27:48 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 5 Aug 2010 20:27:48 +0200 Subject: [Rxtx] Project Status References: <577984.5133.qm@web63104.mail.re1.yahoo.com> Message-ID: <773891141DFE46D59C77BF2380F1DF4B@mdam2> Hi, please explain shortly here what the problem was and solution. You will be joined to a virtual RXTX team - I promise :) Regards Mariusz ----- Original Message ----- From: "Adrian Crum" To: Sent: Thursday, August 05, 2010 7:59 PM Subject: Re: [Rxtx] Project Status Thanks Mariusz. The problems I fixed on my local copy are *real* problems that have been reported in the bug tracker. They are not configuration issues. -Adrian --- On Thu, 8/5/10, M.Dec-GM wrote: > Hi, > Piiiiiiiiiiiiiiiiiiiiiii.... > RXTX Status Message: Do_It_Your_Self. > Piiiiiiiiiiiiiiiiiiiii > EOM > > Now without jokes - in many cases problems are not big and > you may ask here. > There is a lot of not well documented configuration > tricks. > From the other side - a lot of users don't uderstand > transmission's problems and have problem at all... > This is a major part of the "bugs". > I am using very old 2.2pre without problems and I am > tracing this list - sometimes I can help. > On this mailing list there is a lot of solutions as well. > > Regards > Mariusz > > > > ----- Original Message ----- > From: "Adrian Crum" > To: > Sent: Thursday, August 05, 2010 7:28 PM > Subject: [Rxtx] Project Status > > > >I spent the last two weeks evaluating RxTx and fixing a > few problems on my local copy. > > > > I might be wrong, but it seems to me this project has > been abandoned. The latest CVS revision is over a year old, > and prior to that the revisions are 4 years old. There are a > lot of bug reports that have been ignored. The author > doesn't respond to emails. > > > > So my questions is: What is the status of this > project? > > > > -Adrian Crum > > > > > > > > > > _______________________________________________ > > 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 adrian.crum at yahoo.com Thu Aug 5 13:04:56 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:04:56 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status Message-ID: <662027.20175.qm@web63101.mail.re1.yahoo.com> Oops, Yahoo replied directly to Trent and not to the ml. --- On Thu, 8/5/10, Adrian Crum wrote: > Thanks Trent. > > I understand how the open source community works - I've > been involved with an Apache project for over 6 years. > > To be specific, I fixed some multi-threaded issues in my > local copy. I did that because I saw that the issue was > raised on the ml, but it appeared nothing was done about it. > So I just fixed it myself. > > The other issue I'm having is one that gets mentioned a lot > - RxTx crashes the JRE when a communications link is broken. > There is a patch in the bug tracker that fixes it. I have > applied that patch to my local copy and I'm in the process > of testing it. > > Which bring me back to my original post. If I verify the > crashing JRE bug fix works, what happens next? Will it get > committed? And if I submit the multi-threaded fix to the bug > tracker, will it get committed too? > > Looking at the bug tracker and the repository together, it > appears things don't get committed very often. Then again, > maybe I'm looking at the wrong repository. > > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi > wrote: > > > From: Trent Jarvi > > Subject: Re: [Rxtx] Project Status > > To: "Adrian Crum" > > Cc: rxtx at qbang.org > > Date: Thursday, August 5, 2010, 10:59 AM > > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > > > Thanks Mariusz. > > > > > > The problems I fixed on my local copy are *real* > > problems that have been reported in the bug tracker. > They > > are not configuration issues. > > > > > > -Adrian > > > > > > > The way to get fixes into RXTX is to post individual > code > > fixes for individual problems to the list for group > > review.? Often when someone talks about their local > > fixes, they want to dump whitespace changes and > everything > > else along with switching from CVS because....? If > you > > have a clear fix for a clear problem with no side > effects, > > it can get in. > > > > The bug reports are not a contract for support in any > > fashion.? They are to help people identify known > issues > > and potential issues they want to work on. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > From n.zrelli at tu-bs.de Thu Aug 5 13:24:29 2010 From: n.zrelli at tu-bs.de (Nejd Zrelli) Date: Thu, 05 Aug 2010 21:24:29 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> Message-ID: <4C5B0FED.8010608@tu-bs.de> Thank you fr the reply, > Do you mean that the serialEvent is triggered prior to a complete > message being received? no I didn't mean this, I mean that the statements in the function serialevent() are not all processed! I think a possible reason is the java object life time but I'm not sure. > BTW: if you protocol required data sends at regular periods then use a > separate thread rather than abusing the event handler thread. Use > timeouts appropriate to the devices that are communicating. my protocol should handel the data so fast as the communication allow it. That's why I used the data-received-event to trigger the next sending of the data. I can't figure out a better solution. Regards, Nejd Zrelli From tjarvi at qbang.org Thu Aug 5 13:03:31 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 13:03:31 -0600 (MDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <662027.20175.qm@web63101.mail.re1.yahoo.com> References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. http://bugzilla.qbang.org/show_bug.cgi?id=144 There was a rework of the fix. You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. On Thu, 5 Aug 2010, Adrian Crum wrote: > Oops, Yahoo replied directly to Trent and not to the ml. > > --- On Thu, 8/5/10, Adrian Crum wrote: >> Thanks Trent. >> >> I understand how the open source community works - I've >> been involved with an Apache project for over 6 years. >> >> To be specific, I fixed some multi-threaded issues in my >> local copy. I did that because I saw that the issue was >> raised on the ml, but it appeared nothing was done about it. >> So I just fixed it myself. >> >> The other issue I'm having is one that gets mentioned a lot >> - RxTx crashes the JRE when a communications link is broken. >> There is a patch in the bug tracker that fixes it. I have >> applied that patch to my local copy and I'm in the process >> of testing it. >> >> Which bring me back to my original post. If I verify the >> crashing JRE bug fix works, what happens next? Will it get >> committed? And if I submit the multi-threaded fix to the bug >> tracker, will it get committed too? >> >> Looking at the bug tracker and the repository together, it >> appears things don't get committed very often. Then again, >> maybe I'm looking at the wrong repository. >> >> -Adrian >> >> --- On Thu, 8/5/10, Trent Jarvi >> wrote: >> >>> From: Trent Jarvi >>> Subject: Re: [Rxtx] Project Status >>> To: "Adrian Crum" >>> Cc: rxtx at qbang.org >>> Date: Thursday, August 5, 2010, 10:59 AM >>> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>> >>>> Thanks Mariusz. >>>> >>>> The problems I fixed on my local copy are *real* >>> problems that have been reported in the bug tracker. >> They >>> are not configuration issues. >>>> >>>> -Adrian >>>> >>> >>> The way to get fixes into RXTX is to post individual >> code >>> fixes for individual problems to the list for group >>> review.? Often when someone talks about their local >>> fixes, they want to dump whitespace changes and >> everything >>> else along with switching from CVS because....? If >> you >>> have a clear fix for a clear problem with no side >> effects, >>> it can get in. >>> >>> The bug reports are not a contract for support in any >>> fashion.? They are to help people identify known >> issues >>> and potential issues they want to work on. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> >> >> >> > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Thu Aug 5 13:33:01 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 5 Aug 2010 20:33:01 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <4C5B0FED.8010608@tu-bs.de> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: On 5 August 2010 20:24, Nejd Zrelli wrote: > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. I can come up with scenarios for this but it won't necessarily help you! Just post your code and I'll fix it for you. Regards, Michael Erskine. From adrian.crum at yahoo.com Thu Aug 5 13:41:49 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 12:41:49 -0700 (PDT) Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: Message-ID: <923175.10576.qm@web63103.mail.re1.yahoo.com> Cool - thanks! That is the patch I'm testing. Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: Re: [Rxtx] Fw: Re: Project Status > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 12:03 PM > > There has not been alot of commits in the past 2 years but > the code base > is working for many people.? Just make sure you get on > the right branch in > CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla > that was done as > a 20% project and that probably is the disconnected > device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying > them.? The bug > tracker is a good place to start and just paste a link here > for people to > comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Oops, Yahoo replied directly to Trent and not to the > ml. > > > > --- On Thu, 8/5/10, Adrian Crum > wrote: > >> Thanks Trent. > >> > >> I understand how the open source community works - > I've > >> been involved with an Apache project for over 6 > years. > >> > >> To be specific, I fixed some multi-threaded issues > in my > >> local copy. I did that because I saw that the > issue was > >> raised on the ml, but it appeared nothing was done > about it. > >> So I just fixed it myself. > >> > >> The other issue I'm having is one that gets > mentioned a lot > >> - RxTx crashes the JRE when a communications link > is broken. > >> There is a patch in the bug tracker that fixes it. > I have > >> applied that patch to my local copy and I'm in the > process > >> of testing it. > >> > >> Which bring me back to my original post. If I > verify the > >> crashing JRE bug fix works, what happens next? > Will it get > >> committed? And if I submit the multi-threaded fix > to the bug > >> tracker, will it get committed too? > >> > >> Looking at the bug tracker and the repository > together, it > >> appears things don't get committed very often. > Then again, > >> maybe I'm looking at the wrong repository. > >> > >> -Adrian > >> > >> --- On Thu, 8/5/10, Trent Jarvi > >> wrote: > >> > >>> From: Trent Jarvi > >>> Subject: Re: [Rxtx] Project Status > >>> To: "Adrian Crum" > >>> Cc: rxtx at qbang.org > >>> Date: Thursday, August 5, 2010, 10:59 AM > >>> > >>> On Thu, 5 Aug 2010, Adrian Crum wrote: > >>> > >>>> Thanks Mariusz. > >>>> > >>>> The problems I fixed on my local copy are > *real* > >>> problems that have been reported in the bug > tracker. > >> They > >>> are not configuration issues. > >>>> > >>>> -Adrian > >>>> > >>> > >>> The way to get fixes into RXTX is to post > individual > >> code > >>> fixes for individual problems to the list for > group > >>> review.? Often when someone talks about their > local > >>> fixes, they want to dump whitespace changes > and > >> everything > >>> else along with switching from CVS > because....? If > >> you > >>> have a clear fix for a clear problem with no > side > >> effects, > >>> it can get in. > >>> > >>> The bug reports are not a contract for support > in any > >>> fashion.? They are to help people identify > known > >> issues > >>> and potential issues they want to work on. > >>> > >>> -- > >>> Trent Jarvi > >>> tjarvi at qbang.org > >>> > >> > >> > >> > >> > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From aawolfe at gmail.com Thu Aug 5 14:51:01 2010 From: aawolfe at gmail.com (Aaron Wolfe) Date: Thu, 5 Aug 2010 16:51:01 -0400 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, Aug 5, 2010 at 3:41 PM, Adrian Crum wrote: > Cool - thanks! > > That is the patch I'm testing. > > Btw, if it's not too much trouble, could you configure mailman to put rxtx at qbang.org in the reply-to field of the mail headers? > Please, do not do this. The current configuration is correct. > -Adrian > > --- On Thu, 8/5/10, Trent Jarvi wrote: > >> From: Trent Jarvi >> Subject: Re: [Rxtx] Fw: Re: ?Project Status >> To: "Adrian Crum" >> Cc: rxtx at qbang.org >> Date: Thursday, August 5, 2010, 12:03 PM >> >> There has not been alot of commits in the past 2 years but >> the code base >> is working for many people.? Just make sure you get on >> the right branch in >> CVS as the CVS page mentions. >> >> I think I may have missed one commit that is in Bugzilla >> that was done as >> a 20% project and that probably is the disconnected >> device. >> >> http://bugzilla.qbang.org/show_bug.cgi?id=144 >> >> There was a rework of the fix. >> >> You can get fixes into CVS by posting them here and trying >> them.? The bug >> tracker is a good place to start and just paste a link here >> for people to >> comment on the fix if they desire. >> >> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >> > Oops, Yahoo replied directly to Trent and not to the >> ml. >> > >> > --- On Thu, 8/5/10, Adrian Crum >> wrote: >> >> Thanks Trent. >> >> >> >> I understand how the open source community works - >> I've >> >> been involved with an Apache project for over 6 >> years. >> >> >> >> To be specific, I fixed some multi-threaded issues >> in my >> >> local copy. I did that because I saw that the >> issue was >> >> raised on the ml, but it appeared nothing was done >> about it. >> >> So I just fixed it myself. >> >> >> >> The other issue I'm having is one that gets >> mentioned a lot >> >> - RxTx crashes the JRE when a communications link >> is broken. >> >> There is a patch in the bug tracker that fixes it. >> I have >> >> applied that patch to my local copy and I'm in the >> process >> >> of testing it. >> >> >> >> Which bring me back to my original post. If I >> verify the >> >> crashing JRE bug fix works, what happens next? >> Will it get >> >> committed? And if I submit the multi-threaded fix >> to the bug >> >> tracker, will it get committed too? >> >> >> >> Looking at the bug tracker and the repository >> together, it >> >> appears things don't get committed very often. >> Then again, >> >> maybe I'm looking at the wrong repository. >> >> >> >> -Adrian >> >> >> >> --- On Thu, 8/5/10, Trent Jarvi >> >> wrote: >> >> >> >>> From: Trent Jarvi >> >>> Subject: Re: [Rxtx] Project Status >> >>> To: "Adrian Crum" >> >>> Cc: rxtx at qbang.org >> >>> Date: Thursday, August 5, 2010, 10:59 AM >> >>> >> >>> On Thu, 5 Aug 2010, Adrian Crum wrote: >> >>> >> >>>> Thanks Mariusz. >> >>>> >> >>>> The problems I fixed on my local copy are >> *real* >> >>> problems that have been reported in the bug >> tracker. >> >> They >> >>> are not configuration issues. >> >>>> >> >>>> -Adrian >> >>>> >> >>> >> >>> The way to get fixes into RXTX is to post >> individual >> >> code >> >>> fixes for individual problems to the list for >> group >> >>> review.? Often when someone talks about their >> local >> >>> fixes, they want to dump whitespace changes >> and >> >> everything >> >>> else along with switching from CVS >> because....? If >> >> you >> >>> have a clear fix for a clear problem with no >> side >> >> effects, >> >>> it can get in. >> >>> >> >>> The bug reports are not a contract for support >> in any >> >>> fashion.? They are to help people identify >> known >> >> issues >> >>> and potential issues they want to work on. >> >>> >> >>> -- >> >>> 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 Thu Aug 5 14:40:10 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 5 Aug 2010 14:40:10 -0600 (MDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <923175.10576.qm@web63103.mail.re1.yahoo.com> References: <923175.10576.qm@web63103.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > Btw, if it's not too much trouble, could you configure mailman to put > rxtx at qbang.org in the reply-to field of the mail headers? > > -Adrian We can try it and see if anyone objects. Some people like it http://www.metasystema.net/essays/reply-to.html Some people don't http://www.unicom.com/pw/reply-to-harmful.html From adrian.crum at yahoo.com Thu Aug 5 15:28:44 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:28:44 -0700 (PDT) Subject: [Rxtx] Need help with CVS Message-ID: <4546.17451.qm@web63101.mail.re1.yahoo.com> If I download the rxtx-2.1-7r2.zip file, unzip it, apply changes, then try to create a patch, I get an error because it's logging into the wrong location: Logging in to :pserver:anonymous at cvs.milestonesolutions.com:2401:/usr/local/cvsroot If I do a checkout from the url pserver:anonymous at qbang.org:/var/cvs/cvsroot, everything works as expected - creating a patch logs me in as anonymous. I tried browsing the repository, but I can't seem to make sense of the layout. How do I get CVS to work on previous versions? -Adrian From adrian.crum at yahoo.com Thu Aug 5 15:31:13 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 14:31:13 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: Message-ID: <369589.97410.qm@web63107.mail.re1.yahoo.com> Thanks! I'm the former. ;-) Replying to this list will be inconvenient if I have to keep C&P the ml address in the To: field. -Adrian --- On Thu, 8/5/10, Trent Jarvi wrote: > From: Trent Jarvi > Subject: (modifying the reply-to field) > To: "Adrian Crum" > Cc: rxtx at qbang.org > Date: Thursday, August 5, 2010, 1:40 PM > > > On Thu, 5 Aug 2010, Adrian Crum wrote: > > > Btw, if it's not too much trouble, could you configure > mailman to put > > rxtx at qbang.org in > the reply-to field of the mail headers? > > > > -Adrian > > We can try it and see if anyone objects. > > Some people like it > > ??? http://www.metasystema.net/essays/reply-to.html > > Some people don't > > ??? http://www.unicom.com/pw/reply-to-harmful.html > From frans_nieuwerth at nl.ibm.com Thu Aug 5 20:04:25 2010 From: frans_nieuwerth at nl.ibm.com (Frans Nieuwerth) Date: Fri, 6 Aug 2010 04:04:25 +0200 Subject: [Rxtx] AUTO: Frans Nieuwerth/Netherlands/IBM is out of the office until (returning 09-08-2010) Message-ID: I am out of the office until 09-08-2010. I will be out of the office for our summer vacation trip until August 9th. In this period I will have limited access to email and voicemail. For urgent matters on Energy and Utilities, contact Alex Bouw, at alex.bouw at nl.ibm.com. For urgent matters related to the ING MDM PoI project, contact Jeroen Veenstra, at jveenstr at nl.ibm.com Otherwise leave me a voicemail on +31 6 2292 5490, or write me an email for my attention when I return. See you in August. Frans Note: This is an automated response to your message "[Rxtx] (modifying the reply-to field)" sent on 5/8/10 22:40:10. This is the only notification you will receive while this person is away. From lists at iDIAcomputing.com Thu Aug 5 20:19:31 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 22:19:31 -0400 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <369589.97410.qm@web63107.mail.re1.yahoo.com> References: <369589.97410.qm@web63107.mail.re1.yahoo.com> Message-ID: <4C5B7133.5040502@iDIAcomputing.com> On 8/5/10 5:31 PM, Adrian Crum wrote: > Thanks! > > I'm the former. ;-) Replying to this list will be inconvenient if I > have to keep C&P the ml address in the To: field. Thunderbird (3.0.6) has /finally/ added a "reply list" button. It's a shame it's taken MUAs so long to do the sensible thing. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From adrian.crum at yahoo.com Thu Aug 5 21:01:45 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 20:01:45 -0700 (PDT) Subject: [Rxtx] Bug Tracker Message-ID: <603315.86346.qm@web63102.mail.re1.yahoo.com> I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. Could someone check on it for me please? I used this email address. Thanks much! -Adrian From adrian.crum at yahoo.com Thu Aug 5 23:31:00 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Thu, 5 Aug 2010 22:31:00 -0700 (PDT) Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <4C5B7133.5040502@iDIAcomputing.com> Message-ID: <656146.37799.qm@web63105.mail.re1.yahoo.com> --- On Thu, 8/5/10, George Dinwiddie wrote: > On 8/5/10 5:31 PM, Adrian Crum > wrote: > > Thanks! > > > > I'm the former. ;-) Replying to this list will be > inconvenient if I > > have to keep C&P the ml address in the To: field. > > Thunderbird (3.0.6) has /finally/ added a "reply list" > button.? It's a shame it's taken MUAs so long to do the > sensible thing. Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. -Adrian From george.dma at gmail.com Thu Aug 5 23:45:37 2010 From: george.dma at gmail.com (George H) Date: Fri, 6 Aug 2010 08:45:37 +0300 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: <656146.37799.qm@web63105.mail.re1.yahoo.com> References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: I like this new setup. I used to have to do "reply-to all" in gmail and that option is a bit hidden. Now this is much easier. -- George H george.dma at gmail.com On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > --- On Thu, 8/5/10, George Dinwiddie wrote: >> On 8/5/10 5:31 PM, Adrian Crum >> wrote: >> > Thanks! >> > >> > I'm the former. ;-) Replying to this list will be >> inconvenient if I >> > have to keep C&P the ml address in the To: field. >> >> Thunderbird (3.0.6) has /finally/ added a "reply list" >> button.? It's a shame it's taken MUAs so long to do the >> sensible thing. > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Aug 6 00:19:01 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 6 Aug 2010 08:19:01 +0200 Subject: [Rxtx] poor hardware -> rxtx crash? In-Reply-To: <201008041609.28061.lucio@sulweb.org> References: <201008041609.28061.lucio@sulweb.org> Message-ID: <201008060819.01425.lucio@sulweb.org> In data mercoled? 04 agosto 2010 16:09:27, Lucio Crusca ha scritto: > Are you aware of any code paths in rxtx that can make the library reach a > System.exit()? Or is it possible that the native part of the library makes > the whole application crash/exit? Is there anything I can do to spot the > problem? Wonderful list! A few posts after mine I got the answer (I suppose): http://bugzilla.qbang.org/show_bug.cgi?id=144 Only one doubt, being a bug of the native part of the library, is it reasonable to assume that this bug affects Linux version of RxTx also? From vinzenz.weber at techforce.at Fri Aug 6 02:58:43 2010 From: vinzenz.weber at techforce.at (Vinzenz-Emanuel Weber) Date: Fri, 6 Aug 2010 10:58:43 +0200 Subject: [Rxtx] Fw: Re: Project Status In-Reply-To: References: <662027.20175.qm@web63101.mail.re1.yahoo.com> Message-ID: <5F5BFA47-E1E7-4A0A-B5CC-2666630EE118@techforce.at> I am extremely happy to see some movement here on the list talking about the project status. it is true, there is a lot going on on the list and it for sure is NOT dead, although it would be great if there was more avtivity on CVS Vinzenz ;) On 05.08.2010, at 21:03, Trent Jarvi wrote: > > There has not been alot of commits in the past 2 years but the code base is working for many people. Just make sure you get on the right branch in CVS as the CVS page mentions. > > I think I may have missed one commit that is in Bugzilla that was done as a 20% project and that probably is the disconnected device. > > http://bugzilla.qbang.org/show_bug.cgi?id=144 > > There was a rework of the fix. > > You can get fixes into CVS by posting them here and trying them. The bug tracker is a good place to start and just paste a link here for people to comment on the fix if they desire. > > On Thu, 5 Aug 2010, Adrian Crum wrote: > >> Oops, Yahoo replied directly to Trent and not to the ml. >> >> --- On Thu, 8/5/10, Adrian Crum wrote: >>> Thanks Trent. >>> >>> I understand how the open source community works - I've >>> been involved with an Apache project for over 6 years. >>> >>> To be specific, I fixed some multi-threaded issues in my >>> local copy. I did that because I saw that the issue was >>> raised on the ml, but it appeared nothing was done about it. >>> So I just fixed it myself. >>> >>> The other issue I'm having is one that gets mentioned a lot >>> - RxTx crashes the JRE when a communications link is broken. >>> There is a patch in the bug tracker that fixes it. I have >>> applied that patch to my local copy and I'm in the process >>> of testing it. >>> >>> Which bring me back to my original post. If I verify the >>> crashing JRE bug fix works, what happens next? Will it get >>> committed? And if I submit the multi-threaded fix to the bug >>> tracker, will it get committed too? >>> >>> Looking at the bug tracker and the repository together, it >>> appears things don't get committed very often. Then again, >>> maybe I'm looking at the wrong repository. >>> >>> -Adrian >>> >>> --- On Thu, 8/5/10, Trent Jarvi >>> wrote: >>> >>>> From: Trent Jarvi >>>> Subject: Re: [Rxtx] Project Status >>>> To: "Adrian Crum" >>>> Cc: rxtx at qbang.org >>>> Date: Thursday, August 5, 2010, 10:59 AM >>>> >>>> On Thu, 5 Aug 2010, Adrian Crum wrote: >>>> >>>>> Thanks Mariusz. >>>>> >>>>> The problems I fixed on my local copy are *real* >>>> problems that have been reported in the bug tracker. >>> They >>>> are not configuration issues. >>>>> >>>>> -Adrian >>>>> >>>> >>>> The way to get fixes into RXTX is to post individual >>> code >>>> fixes for individual problems to the list for group >>>> review. Often when someone talks about their local >>>> fixes, they want to dump whitespace changes and >>> everything >>>> else along with switching from CVS because.... If >>> you >>>> have a clear fix for a clear problem with no side >>> effects, >>>> it can get in. >>>> >>>> The bug reports are not a contract for support in any >>>> fashion. They are to help people identify known >>> issues >>>> and potential issues they want to work on. >>>> >>>> -- >>>> 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 -- DI (FH) Vinzenz-Emanuel Weber Software Engineer software for every case web / pc / embedded / mobile +436607675979 Wiedner G?rtel 26 A-1040 Wien http://www.techforce.at From mariusz.dec at gmail.com Fri Aug 6 11:26:20 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 6 Aug 2010 19:26:20 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> Message-ID: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Hi Nejd I have had same challenge - data handling as fast as possible. Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. If data comes in, I am parsing it and if data is ok I am generating Java exception with data to main application. I have published an example in 2009 November in the thread RXTX close() problem solved. Analyse it and if you will have more question, ask. Regards Mariusz ----- Original Message ----- From: "Nejd Zrelli" To: Sent: Thursday, August 05, 2010 9:24 PM Subject: Re: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) > Thank you fr the reply, > >> Do you mean that the serialEvent is triggered prior to a complete >> message being received? > no I didn't mean this, I mean that the statements in the function > serialevent() are not all processed! > I think a possible reason is the java object life time but I'm not sure. > >> BTW: if you protocol required data sends at regular periods then use a >> separate thread rather than abusing the event handler thread. Use >> timeouts appropriate to the devices that are communicating. > my protocol should handel the data so fast as the communication allow it. > That's why I used the data-received-event to trigger the next sending of > the data. > I can't figure out a better solution. > > Regards, > Nejd Zrelli > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From msemtd at googlemail.com Fri Aug 6 12:03:57 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 6 Aug 2010 19:03:57 +0100 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: <188AD26EF96F4DE49842C9D12C159BEE@mdam2> References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: On 6 August 2010 18:26, M.Dec-GMail wrote: > Hi Nejd > I have had same challenge - data handling as fast as possible. > Events was mysterious and slow so I did it using separate Java thread for continious reading serial buffer from Java side. > If data comes in, I am parsing it ?and if data is ok I am generating Java exception with data to main application. > I have published an example in 2009 November in the thread RXTX close() problem solved. > Analyse it and if you will have more question, ask. > Regards > Mariusz I have never found this to be necessary -- the classes I wrote to interface with RXTX have been running continuously at many sites within many applications on hundreds of serial ports! I have never had any problems of this nature and yet my event handlers are ridiculously simple. I'll post the code when I get to a development machine (although I'm sure I've posted it before). Regards, Michael. From tjarvi at qbang.org Fri Aug 6 12:23:45 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 6 Aug 2010 12:23:45 -0600 (MDT) Subject: [Rxtx] Bug Tracker In-Reply-To: <603315.86346.qm@web63102.mail.re1.yahoo.com> References: <603315.86346.qm@web63102.mail.re1.yahoo.com> Message-ID: On Thu, 5 Aug 2010, Adrian Crum wrote: > I created an account in the bug tracker about 8 hours ago. I never received an email with further instructions. I tried to sign up again - thinking I may have misspelled something, and it said I was already a member. I requested a password change to see if that would come through - no luck. > > Could someone check on it for me please? I used this email address. Thanks much! > Sent an email off list to fix the issue. From andy at g0poy.com Fri Aug 6 15:24:17 2010 From: andy at g0poy.com (Andy Eskelson) Date: Fri, 6 Aug 2010 22:24:17 +0100 Subject: [Rxtx] (modifying the reply-to field) In-Reply-To: References: <4C5B7133.5040502@iDIAcomputing.com> <656146.37799.qm@web63105.mail.re1.yahoo.com> Message-ID: <20100806222417.75979309@workstation.site> If you have set up your mail package to filter the RxTx group postings into a separate folder, check the options on that folder. Many mail programs will allow you to set up from and to addresses etc. on a folder by folder basis, so that when you reply they automatically get filled in. I use claws mail on Linux, and I'm fairly sure that things like evolution has a similar ability, and maybe even firefox. Regards Andy On Fri, 6 Aug 2010 08:45:37 +0300 George H wrote: > I like this new setup. > I used to have to do "reply-to all" in gmail and that option is a bit hidden. > Now this is much easier. > -- > George H > george.dma at gmail.com > > > > On Fri, Aug 6, 2010 at 8:31 AM, Adrian Crum wrote: > > --- On Thu, 8/5/10, George Dinwiddie wrote: > >> On 8/5/10 5:31 PM, Adrian Crum > >> wrote: > >> > Thanks! > >> > > >> > I'm the former. ;-) Replying to this list will be > >> inconvenient if I > >> > have to keep C&P the ml address in the To: field. > >> > >> Thunderbird (3.0.6) has /finally/ added a "reply list" > >> button.? It's a shame it's taken MUAs so long to do the > >> sensible thing. > > > > Sensible or not, what's important in an open source community is encouraging participation - preferably by making participation easy and convenient. > > > > -Adrian > > > > > > > > > > _______________________________________________ > > 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 mariusz.dec at gmail.com Fri Aug 6 21:56:36 2010 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Sat, 7 Aug 2010 05:56:36 +0200 Subject: [Rxtx] lifetime of the serialEvent(SerialPortEvent args0) In-Reply-To: References: <4C521FA7.1080803@tu-bs.de> <4C5B0FED.8010608@tu-bs.de> <188AD26EF96F4DE49842C9D12C159BEE@mdam2> Message-ID: 2010/8/6 Michael Erskine > On 6 August 2010 18:26, M.Dec-GMail wrote: > > Hi Nejd > > I have had same challenge - data handling as fast as possible. > > Events was mysterious and slow so I did it using separate Java thread for > continious reading serial buffer from Java side. > > If data comes in, I am parsing it and if data is ok I am generating Java > exception with data to main application. > > I have published an example in 2009 November in the thread RXTX close() > problem solved. > > Analyse it and if you will have more question, ask. > > Regards > > Mariusz > > I have never found this to be necessary -- the classes I wrote to > interface with RXTX have been running continuously at many sites > within many applications on hundreds of serial ports! I have never had > any problems of this nature and yet my event handlers are ridiculously > simple. I'll post the code when I get to a development machine > (although I'm sure I've posted it before). > > > Regards, > Michael. > Yeah, And by the way you have defined the worst side of the RXTX - very short list of the working examples :( I have worked over "stupid & simple" close many weeks, because of NO WORKING examples and no docs in one place. I have discussed this problem with Trent about one year ago... We (Steffen, Ivan, me) have discussed some problems with Events without final success about one year ago, you waren't there :(. And here (in the Neid's post) you may see that problem with events comes back. I dod not say that Events do not work, I would like to help Neid using my well tested way. Going